On Fri, Dec 19, 2008 at 11:35 AM, Carlos O'Donell <carlos@xxxxxxxxxxxxxxxx> wrote: > On Fri, Dec 19, 2008 at 11:28 AM, Kyle McMartin <kyle@xxxxxxxxxxxxx> wrote: >> On Fri, Dec 19, 2008 at 11:23:39AM -0500, Carlos O'Donell wrote: >>> On Fri, Dec 19, 2008 at 11:13 AM, John David Anglin >>> <dave@xxxxxxxxxxxxxxxxxx> wrote: >>> >> > For future reference, in mmu_context.h. Bloody tricky mtctl() macro >>> >> > doesn't take a prefix, just the numeric cr #. >>> >> >>> >> Evil. >>> > >>> > If this is a problem with the WD bit, the problem is likely here: >>> > >>> > mtctl(context >> (SPACEID_SHIFT - 1),8); >>> > >>> > It's possible this might set the WD bit depending on the alignment >>> > of context and the value of SPACEID_SHIFT on your machine. If you >>> > can duplicate, maybe add a BUG_ON. On hppa64, all structs are passed >>> > by value, so the alignment of context may only be BIGGEST_ALIGNMENT. >>> >>> The value of context is a space id (the value returned by alloc_sid()) >>> and is not related to any alignment? >> >> It's a typedef to an unsigned long. I'm not sure we've seen this on a >> 64-bit kernel (which is the SPACEID_SHIFT one.) >> >> On a 32-bit kernel (where I've been able to reproduce this) we do a >> leftshift by one, so the WD bit is guaranteed to be 0. > > John has a good point though, we might as well assert that? In alloc_sid() when we allocate the space id? c. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
