From patchwork Mon Mar 2 13:54:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 445293 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 4B9731400D5 for ; Tue, 3 Mar 2015 00:56:47 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753869AbbCBNzh (ORCPT ); Mon, 2 Mar 2015 08:55:37 -0500 Received: from cantor2.suse.de ([195.135.220.15]:60530 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753537AbbCBNzf (ORCPT ); Mon, 2 Mar 2015 08:55:35 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3AB65AC47; Mon, 2 Mar 2015 13:55:34 +0000 (UTC) From: Michal Hocko To: Cc: Andrew Morton , Johannes Weiner , David Rientjes , Dave Chinner , "Theodore Ts'o" , Mel Gorman , Tetsuo Handa , "David S. Miller" , sparclinux@vger.kernel.org, Vipul Pandya , netdev@vger.kernel.org, LKML Subject: [RFC 1/4] mm: Clarify __GFP_NOFAIL deprecation status Date: Mon, 2 Mar 2015 14:54:40 +0100 Message-Id: <1425304483-7987-2-git-send-email-mhocko@suse.cz> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1425304483-7987-1-git-send-email-mhocko@suse.cz> References: <1425304483-7987-1-git-send-email-mhocko@suse.cz> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org __GFP_NOFAIL is documented as a deprecated flag since 478352e789f5 (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 effort failure because there is no good failure policy then using __GFP_NOFAIL is preferable to opencoding the loop outside of the allocator. Signed-off-by: Michal Hocko Acked-by: David Rientjes --- include/linux/gfp.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 51bd1e72a917..0cf9c2772988 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -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 carefuly + * (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. *