Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL

[tytso]

On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
> 
> From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxx>
> Cc: Joe Perches <joe@xxxxxxxxxxx>
> Cc: Theodore Ts'o <tytso@xxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/