> > Bug-Entry :
http://bugzilla.kernel.org/show_bug.cgi?id=9978
> > Subject : 2.6.25-rc1: volanoMark regression
> > Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > Date : 2008-02-13 10:30 (44 days old)
> > References :
http://lkml.org/lkml/2008/2/13/128
> >
http://lkml.org/lkml/2008/3/12/52
> >
http://lkml.org/lkml/2008/3/18/81
> > Handled-By : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Balbir Singh <balbir@linux.vnet.ibm.com>
>
> Hmm. It is a regression on one machine (2x quad-core stoakley), but not
> another (4x quad-core tigerton).
>
> Interestingly, the stoakley box numbers have apparently been all over the
> map.
>
> > Bug-Entry :
http://bugzilla.kernel.org/show_bug.cgi?id=10318
> > Subject : WARNING: at arch/x86/mm/highmem_32.c:43 kmap_atomic_prot+0x87/0x184()
> > Submitter : Pawel Staszewski <pstaszewski@artcom.pl>
> > Date : 2008-03-25 02:50 (3 days old)
>
> Andrew and seems to have debugged this down to a kzalloc(GFP_ATOMIC) or
> similar.
>
> I wonder if the bug is in that commit
> 3811dbf67162bd08412f1b0e02e554f353e93bdb ("SLUB: remove useless masking
> of GFP_ZERO"), because I don't think that masking was at all useless and I
> think my original 7fd272550bd43cc1d7289ef0ab2fa50de137e767 was correct.
>
> That apparently bogus commit says "GFP_ZERO is already masked out in
> new_slab()", but gfpflags is not just used for new_slab(), but for
> kmalloc_large() too. Which does *not* clear GFP_ZERO.
>
> Pawel, does reverting 3811dbf67162bd08412f1b0e02e554f353e93bdb fix it for
> you?
>
> Also, Rafael - do these reminder emails also go to the people who are
> mentioned in the regressions (especially people who are set up as being
> "hanled-by" or having patches for the problem)?