[lkml]   [2011]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mke2fs: page allocation failure w/ kernel 2.6.37
On Friday, 7 January 2011, Ted Ts'o <> wrote:
> On Fri, Jan 07, 2011 at 02:45:30PM -0800, David Rientjes wrote:
>> On Wed, 5 Jan 2011, Toralf Förster wrote:
>> > Hello,
>> >
>> > I got this in /var/log/messages today (created a ext2 partition at an external USB drive, worked fine) :
>> >
>> Yeah, this failure is from the kmemleak stack which simply means that
>> debugging tool will be disabled rather than any disruption to the
>> workflow.
>> I'm curious why kmemleak is masking with GFP_KERNEL and GFP_ATOMIC and not
>> allowing users to pass __GFP_NOWARN to suppress this type of failure,
>> especially since the stack trace is already emitted by kmemleak when it is
>> stopped.  Catalin?
> Indeed, is there a reason why the kmemleak code is so noisy?  And can
> it display a more obvious message about what is going on?  It took me
> a while to figure out why it was unhappy, and whether there it was a
> fault of the code it was testing, or just that it could get the memory
> it needed....

Good point, I think kmemleak can always pass __GFP_NOWARN for its own
allocations. Note that these allocations are only for the kmemleak
metadata, the other users just allocate memory with the flags they
requested. When failing, it could also avoid printing call traces
(maybe keep a debug macro in case one wants to track this).

I'll post a patch on Monday.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-01-08 14:13    [W:0.043 / U:3.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site