Commit 64775719 authored by Michal Hocko's avatar Michal Hocko Committed by Linus Torvalds
Browse files

mm: clarify __GFP_NOFAIL deprecation status

__GFP_NOFAIL is documented as a deprecated flag since commit

 ("mm: add comment about deprecation of __GFP_NOFAIL").

This has discouraged people from using it but in some cases an opencoded
endless loop around allocator has been used instead.  So the allocator
is not aware of the de facto __GFP_NOFAIL allocation because this
information was not communicated properly.

Let's make clear that if the allocation context really cannot afford
failure because there is no good failure policy then using __GFP_NOFAIL
is preferable to opencoding the loop outside of the allocator.

[ coding-style fixes]
Signed-off-by: default avatarMichal Hocko <>
Acked-by: default avatarDavid Rientjes <>
Cc: Johannes Weiner <>
Cc: Dave Chinner <>
Cc: "Theodore Ts'o" <>
Cc: Mel Gorman <>
Cc: Tetsuo Handa <>
Cc: "David S. Miller" <>
Cc: Vipul Pandya <>
Cc: Jan Kara <>
Signed-off-by: default avatarAndrew Morton <>
Signed-off-by: default avatarLinus Torvalds <>
parent ac173824
......@@ -57,8 +57,10 @@ struct vm_area_struct;
* _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.
* cannot handle allocation failures. New users should be evaluated carefully
* (and the flag should be used only when there is no reasonable failure policy)
* but it is definitely preferable to use the flag rather than opencode endless
* loop around allocator.
* __GFP_NORETRY: The VM implementation must not retry indefinitely.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment