lkml.org 
[lkml]   [2011]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: mke2fs: page allocation failure w/ kernel 2.6.37
From
On Friday, 7 January 2011, Ted Ts'o <tytso@mit.edu> 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.

Thanks.


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

\
 
 \ /
  Last update: 2011-01-08 14:13    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site