Xen devel - May 2005 - bitopts functions overflowing page boundarys

u.inuse.type_info is at the end of the pfn_info structure, and is
u32 for both x86_32 and x86_64--in this location it can also be the
last 32 bits of a page.

several functions use bitopts.h functions to manipulate this member, and
on x86_64 these functions use u64 instructions, which will overflow the
page boundary, and possibly the end of memory as we see here:

   (XEN) &page->u.inuse.type_info = 0xffff828402fffffc
   (XEN) CPU:    0
   (XEN) EIP:    e010:[<ffff830000129089>]      

   <registers and stack ommitted>

   (XEN) Pagetable walk from ffff828403000000:
   (XEN)  L4 = 00000000016a5063
   (XEN)   L3 = 00000000016a6063
   (XEN)    L2 = 0000000000000000 

   ****************************************
   Panic on CPU0:
   CPU0 FATAL PAGE FAULT
   [error_code=0002]
   Faulting linear address: ffff828403000000
   ****************************************

the attached patch fixes this.

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28 May 2005, at 05:43, Scott Parish wrote:
> u.inuse.type_info is at the end of the pfn_info structure, and is
> u32 for both x86_32 and x86_64--in this location it can also be the
> last 32 bits of a page.
>
> several functions use bitopts.h functions to manipulate this member, 
> and
> on x86_64 these functions use u64 instructions, which will overflow the
> page boundary, and possibly the end of memory as we see here:
You really see this in practise? I''m very surprised. The memory map 
would have to be just big enough that the last pfn_info structure falls 
at the end of an aligned 2MB boundary. If you reduce max_page by 1, 
does the problem disappear?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, May 28, 2005 at 10:01:27AM +0100, Keir Fraser wrote:
> 
> On 28 May 2005, at 05:43, Scott Parish wrote:
> 
> >u.inuse.type_info is at the end of the pfn_info structure, and is
> >u32 for both x86_32 and x86_64--in this location it can also be the
> >last 32 bits of a page.
> >
> >several functions use bitopts.h functions to manipulate this member, 
> >and
> >on x86_64 these functions use u64 instructions, which will overflow the
> >page boundary, and possibly the end of memory as we see here:
> 
> You really see this in practise? I''m very surprised. The memory
map
> would have to be just big enough that the last pfn_info structure falls 
> at the end of an aligned 2MB boundary. If you reduce max_page by 1, 
> does the problem disappear?
Here''s the memory map for one of the boxes we''re seeing this
on:

(XEN) Physical RAM map:
(XEN)  0000000000000000 - 000000000009dc00 (usable)
(XEN)  000000000009dc00 - 00000000000a0000 (reserved)
(XEN)  00000000000d0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000dff60000 (usable)
(XEN)  00000000dff60000 - 00000000dff72000 (ACPI data)
(XEN)  00000000dff72000 - 00000000dff80000 (ACPI NVS)
(XEN)  00000000dff80000 - 00000000e0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec00400 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff80000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000180000000 (usable)

No problem when dom0_mem is less then 2048K; at exactly 2048 we hit
the next sized "order" which can''t be fulfilled from the
0x100-0xdff60
range. All initial allocation for dom0 that i''ve seen that fall in the
"usable" above the hole have the problem i described.

Setting,

  max_page = init_e820(e820_raw, &e820_raw_nr) - 1;

seems to unravel a number of things. shall i preceed to figure out
what all, or is such still needed?

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, May 28, 2005 at 10:51:06AM +0100, Keir Fraser wrote:
> 
> On 28 May 2005, at 10:04, Scott Parish wrote:
> 
> >o problem when dom0_mem is less then 2048K; at exactly 2048 we hit
> >the next sized "order" which can''t be fulfilled from
the 0x100-0xdff60
> >range. All initial allocation for dom0 that i''ve seen that
fall in the
> >"usable" above the hole have the problem i described.
> >
> >Setting,
> >
> >  max_page = init_e820(e820_raw, &e820_raw_nr) - 1;
> >
> >seems to unravel a number of things. shall i preceed to figure out
> >what all, or is such still needed?
> 
> No, I guess this situation just isn''t as unlikely as I though it
would
> be. :-)
> 
> I checked in a fixed up bitops.h that should fix the problem for you 
> without needing new bitop functions.
splendid!

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28 May 2005, at 10:04, Scott Parish wrote:
> o problem when dom0_mem is less then 2048K; at exactly 2048 we hit
> the next sized "order" which can''t be fulfilled from the
0x100-0xdff60
> range. All initial allocation for dom0 that i''ve seen that fall in
the
> "usable" above the hole have the problem i described.
>
> Setting,
>
>   max_page = init_e820(e820_raw, &e820_raw_nr) - 1;
>
> seems to unravel a number of things. shall i preceed to figure out
> what all, or is such still needed?
No, I guess this situation just isn''t as unlikely as I though it would 
be. :-)

I checked in a fixed up bitops.h that should fix the problem for you 
without needing new bitop functions.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel