lkml.org 
[lkml]   [2009]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: upcoming kerneloops.org item: get_page_from_freelist
On Wed, Jun 24, 2009 at 03:07:14PM -0700, Andrew Morton wrote:
> On Wed, 24 Jun 2009 13:40:11 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Wed, 24 Jun 2009, Linus Torvalds wrote:
> > > On Wed, 24 Jun 2009, Andrew Morton wrote:
> > actually makes tons of sense.
>
> I suspect that warning will trigger.
>
> alloc_pages
> -> ...
> -> pageout
> -> ...
> -> get_request
> -> blk_alloc_request
> -> elv_set_request
> -> cfq_set_request
> -> cfq_get_queue
> -> cfq_find_alloc_queue
> -> kmem_cache_alloc_node(__GFP_NOFAIL)
> -> Jens
>
> How much this can happen in practice I don't know, but it looks bad.
>
> > There are other cases where __GFP_NOFAIL doesn't make sense too, and that
> > could be warned about. The __GFP_NORETRY thing was already mentioned.
> > Similarly, !__GFP_WAIT doesn't work with __GFP_NOFAIL - because the nofail
> > obviously relies on being able to do something about the failure case.
> >
> > We might want to also have rules like "in order to have NOFAIL, you need
> > to allow IO and FS accesses".
>
> Sure, that's sane.
>
> fs/jbd/journal.c: new_bh = alloc_buffer_head(GFP_NOFS|__GFP_NOFAIL);
>
> But that isn't :(

Unfortunately there's a lot of "hidden" ones in fs/buffer.c.
alloc_page_buffers with arg3=1, which is used quite a lot in
create_empty_buffers.

Also getblk. Sad.

fsblock FTW :)



\
 
 \ /
  Last update: 2009-06-25 06:09    [from the cache]
©2003-2011 Jasper Spaans