On Thu, 1 Jul 2010, Pekka Enberg wrote:
> > On Mon, 28 Jun 2010, Pekka Enberg wrote:
> >> > + return kzalloc(size, GFP_KERNEL & gfp_allowed_mask);
> >> > else {
> >> > void *ptr = vmalloc(size);
> >> > if (ptr)
> >>
> >> This looks wrong to me. All slab allocators should do gfp_allowed_mask
> >> magic under the hood. Maybe it's triggering kmalloc_large() path that
> >> needs the masking too?
>
> On Tue, Jun 29, 2010 at 6:45 PM, Christoph Lameter
> <cl@xxxxxxxxxxxxxxxxxxxx> wrote:
> > They do gfp_allowed_mask magic. But the checks at function entry of the
> > slabs do not mask the masks so we get false positives without this. All my
> > protest against the checks doing it this IMHO broken way were ignored.
>
> Which checks are those? Are they in SLUB proper or are they introduced
> in one of the SLEB patches? We definitely don't want to expose
> gfp_allowed_mask here.
Argh. The reason for the trouble here is because I moved the
masking of the gfp flags out of the hot path.
The masking of the bits adds to the cache footprint of the hotpaths now in
all slab allocators. Gosh. Why is there constant contamination of the hot
paths with the stuff?
We only need this masking in the hot path if the debugging hooks need it.
Otherwise its fine to defer this to the slow paths.
So how do I get that in there? Add "& gfp_allowed_mask" to the gfp mask
passed to the debugging hooks?
Or add a debug_hooks_alloc() function and make it empty if no debugging
functions are enabled?