Quantcast

bitopts functions overflowing page boundarys

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bitopts functions overflowing page boundarys

Scott Parish
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: [hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

32bit.diff (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bitopts functions overflowing page boundarys

Keir Fraser

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
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bitopts functions overflowing page boundarys

Scott Parish
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: [hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bitopts functions overflowing page boundarys

Keir Fraser

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
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bitopts functions overflowing page boundarys

Scott Parish
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: [hidden email]

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Loading...