[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C73CA24.3060707@fusionio.com>
Date: Tue, 24 Aug 2010 15:33:24 +0200
From: Jens Axboe <jaxboe@...ionio.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Neil Brown <neilb@...e.de>, Alasdair G Kergon <agk@...hat.com>,
Chris Mason <chris.mason@...cle.com>,
Steven Whitehouse <swhiteho@...hat.com>,
Jan Kara <jack@...e.cz>,
Frederic Weisbecker <fweisbec@...il.com>,
"linux-raid@...r.kernel.org" <linux-raid@...r.kernel.org>,
"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
"cluster-devel@...hat.com" <cluster-devel@...hat.com>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"reiserfs-devel@...r.kernel.org" <reiserfs-devel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
On 2010-08-24 15:29, Peter Zijlstra wrote:
> On Tue, 2010-08-24 at 03:50 -0700, David Rientjes wrote:
>> These were added as helper functions for documentation and auditability.
>> No future callers should be added.
>
> git grep GFP_NOFAIL isn't auditable enough?
>
> might as well declare these functions depricated if you really want to
> do this.
Agree, adding a helper function would seem to be going in the reverse
direction imho. Nobody will read that comment on top of the function.
Should be possible to warn at build time for anyone using __GFP_NOFAIL
without wrapping it in a function.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists