[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140322181236.GD23583@thunk.org>
Date: Sat, 22 Mar 2014 14:12:36 -0400
From: tytso@....edu
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Fabian Frederick <fabf@...net.be>,
linux-kernel <linux-kernel@...r.kernel.org>,
reiserfs-devel@...r.kernel.org,
David Rientjes <rientjes@...gle.com>,
Joe Perches <joe@...ches.com>
Subject: Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL
On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
>
> From: Andrew Morton <akpm@...ux-foundation.org>
> Subject: scripts/checkpatch.pl: __GFP_NOFAIL isn't going away
>
> Revert 7e4915e78992eb ("checkpatch: add warning of future __GFP_NOFAIL use").
>
> There are no plans to remove __GFP_NOFAIL.
>
> __GFP_NOFAIL exists to
>
> a) centralise the retry-allocation-for-ever operation into the core
> allocator, which is the appropriate implementation site and
>
> b) permit us to identify code sites which aren't handling memory
> exhaustion appropriately.
>
> Cc: David Rientjes <rientjes@...gle.com>
> Cc: Joe Perches <joe@...ches.com>
> Cc: Theodore Ts'o <tytso@....edu>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
How about also making the following change which inspired the
checkpatch warning?
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0437439..d189872 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -58,9 +58,11 @@ struct vm_area_struct;
* __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
* _might_ fail. This depends upon the particular VM implementation.
*
- * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
- * cannot handle allocation failures. This modifier is deprecated and no new
- * users should be added.
+ * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the
+ * caller cannot handle allocation failures. Callers are strongly
+ * encouraged not to use __GFP_NOFAIL unless the alternative is worse
+ * than OOM killing some random process (i.e., corruption or loss of
+ * some innocent user's data, etc).
*
* __GFP_NORETRY: The VM implementation must not retry indefinitely.
*
--
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/
Powered by blists - more mailing lists