Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

[Nick Piggin]

On Mon, Jun 15, 2009 at 12:48:44PM +0300, Pekka Enberg wrote:
> Hi Nick,
> 
> On Mon, Jun 15, 2009 at 11:18 AM, Heiko Carstens<heiko.carstens@xxxxxxxxxx> wrote:
> > > > I didn't look any deeper into this, but looks to me like doing something like
> > > > schedule_work() this early isn't ok.
> > > >
> > > > This is the conversion that leads to the crash:
> > > >
> > > > -               alloc_bootmem_low(sizeof(struct raw3215_info));
> > > > +               kzalloc(sizeof(struct raw3215_info), GFP_NOWAIT | GFP_DMA);
> > > >
> > > > Might be that I missed something. Maybe some special flag?
> 
> On Mon, Jun 15, 2009 at 12:10:01PM +0300, Pekka Enberg wrote:
> > > Btw, you should not need to use GFP_NOWAIT anymore and GFP_KERNEL
> > > should be fine even during early boot.
> 
> On Mon, 2009-06-15 at 11:41 +0200, Nick Piggin wrote:
> > Is this the agreed way forward? I would like to maybe continue to
> > try having early allocations pass in special flags where possible
> > (it could even be a GFP_BOOT or something). It can make it easier
> > to perhaps reduce branches in core code in future and things can
> > be flagged in warnings....
> > 
> > I just like the idea of keeping such annotations.
> 
> I don't know if we agreed or not but Linus expressed his liking to the
> masking patch (that is merged now).

Yes I do like your patch, but more as the implementation of the
workaround for slab rather than being able to use it to mask
of random bits.


> I was more on the GFP_BOOT side also but I am beginning to like the fact
> that we can just do GFP_KERNEL and expect that to work in a sane way
> during boot (and perhaps later on during suspend). We can probably shave

I'd just not like to give up on it right away. I'm not convinced
that it is a "too hard" problem to have callers figure out the
right context (they do it for all other problems like whether
they can sleep and whether they hold specific types of locks
or whether they can be called in reclaim path etc etc etc).

And it is pretty trivial to add warnings to catch any of these
conditions. So while auditing might not be trivial, we would
likely be able to mop up remainders with some runtime warnings.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/