Messages in this thread | | | Date | Wed, 24 Jun 2009 09:46:22 -0700 | From | Andrew Morton <> | Subject | Re: upcoming kerneloops.org item: get_page_from_freelist |
| |
On Wed, 24 Jun 2009 08:07:53 -0700 Arjan van de Ven <arjan@infradead.org> wrote:
> Hi, > > a new item is coming up fast in the kerneloops.org stats, and it's new > in 2.6.31-rc; > > http://www.kerneloops.org/searchweek.php?search=get_page_from_freelist > > it's this warning in mm/page_alloc.c: > > * __GFP_NOFAIL is not to be used in new code. > * > * All __GFP_NOFAIL callers should be fixed so that they > * properly detect and handle allocation failures. > * > * We most definitely don't want callers attempting to > * allocate greater than single-page units with > * __GFP_NOFAIL. > */ > WARN_ON_ONCE(order > 0); > > > typical backtraces look like > > get_page_from_freelist > __alloc_pages_nodemask > alloc_pages_current > alloc_slab_page > new_slab > __slab_alloc > kmem_cache_alloc_notrace > start_this_handle > jbd2_journal_start > > and > > get_page_from_freelist > __alloc_pages_nodemask > alloc_pages_current > alloc_slab_page > new_slab > __slab_alloc > kmem_cache_alloc_notrace > start_this_handle > journal_start > ext3_journal_start_sb > ext3_journal_start > ext3_dirty_inode > > but there are some other ones as well at the url above. > > > git blame shows that > > commit dab48dab37d2770824420d1e01730a107fade1aa > Author: Andrew Morton <akpm@linux-foundation.org> > Date: Tue Jun 16 15:32:37 2009 -0700 > > introduced this WARN_ON.....
Well yes. Using GFP_NOFAIL on a higher-order allocation is bad. This patch is there to find, name, shame, blame and hopefully fix callers.
A fix for cxgb3 is in the works. slub's design is a big problem.
But we'll probably have to revert it for 2.6.31 :(
| |