linux-kernel - Re: mke2fs: page allocation failure w/ kernel 2.6.37

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AANLkTi=JNOF43ue6CjODXhLTMxmrRTx-7JPdYGvn60mk@mail.gmail.com>
Date:	Sat, 8 Jan 2011 12:47:32 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	"Ted Ts'o" <tytso@....edu>, David Rientjes <rientjes@...gle.com>,
	Toralf Förster <toralf.foerster@....de>,
	Catalin Marinas <catalin.marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: mke2fs: page allocation failure w/ kernel 2.6.37

On Friday, 7 January 2011, Ted Ts'o <tytso@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/