From patchwork Mon Mar 2 21:36:10 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 445437 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 59259140083 for ; Tue, 3 Mar 2015 08:36:32 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="verification failed; unprotected key" header.d=gmail.com header.i=@gmail.com header.b=gWYmSYq/; dkim-adsp=none (unprotected policy); dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755804AbbCBVgP (ORCPT ); Mon, 2 Mar 2015 16:36:15 -0500 Received: from mail-we0-f181.google.com ([74.125.82.181]:36272 "EHLO mail-we0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753730AbbCBVgO (ORCPT ); Mon, 2 Mar 2015 16:36:14 -0500 Received: by wevk48 with SMTP id k48so36060331wev.3; Mon, 02 Mar 2015 13:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fPFxGLlpjYTUsKj9HWrlwWo8uCJP9D0Fb2EN3egZoRU=; b=gWYmSYq/+aIBcLPhtQ26bH8dySeXBZgn5tGs8ye/A7FjxDkW55YzfIXpJwMWNtUbTL cpzSOQM6qazLO9XnEGN+E8C2EWlurID4Tx1H03Sh7COf4YY4t22qczusY/As+HiNNlUj 8FuocFt4BMhC/wXzk3y99o9Cfat9B7RmqXx3vcG6pJdvnBVQIaBUVxFQRjNauwV+xCtC rZfT8vp1Wps4J9rbuWnsmwdyGjQyRLqQHwr+ePZ+U6te5TZMY7a6GmwYCW4D1s6GHagq KfQjbGQR1M+YywhU6oDCTVYwcIkK5Hku52ZJ6+SnNLHIrsCcWFLJh4cP/J/1nzyVZ6Vz 3HXA== X-Received: by 10.180.108.199 with SMTP id hm7mr39250021wib.5.1425332172686; Mon, 02 Mar 2015 13:36:12 -0800 (PST) Received: from localhost (ip-78-45-94-81.net.upcbroadband.cz. [78.45.94.81]) by mx.google.com with ESMTPSA id e18sm20934014wjz.27.2015.03.02.13.36.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 13:36:11 -0800 (PST) Date: Mon, 2 Mar 2015 22:36:10 +0100 From: Michal Hocko To: David Miller Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hannes@cmpxchg.org, rientjes@google.com, david@fromorbit.com, tytso@mit.edu, mgorman@suse.de, penguin-kernel@I-love.SAKURA.ne.jp, sparclinux@vger.kernel.org, vipul@chelsio.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] sparc: clarify __GFP_NOFAIL allocation Message-ID: <20150302213610.GA31974@dhcp22.suse.cz> References: <1425304483-7987-4-git-send-email-mhocko@suse.cz> <20150302.150405.2072800922470200977.davem@davemloft.net> <20150302203304.GA20513@dhcp22.suse.cz> <20150302.154424.30182050492471222.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150302.154424.30182050492471222.davem@davemloft.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon 02-03-15 15:44:24, David S. Miller wrote: [...] > > OK, thanks for the clarification. This wasn't clear from the commit > > which has introduced this code. I will drop this patch. Would you > > accept something like the following instead? > > Sure. Thanks! Acked-by: David S. Miller --- From dac5829e3a1d44ba7759b4188de01f15ddb77b8b Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Mon, 2 Mar 2015 22:27:02 +0100 Subject: [PATCH] sparc: clarify __GFP_NOFAIL allocation 920c3ed74134 ([SPARC64]: Add basic infrastructure for MD add/remove notification.) has added __GFP_NOFAIL for the allocation request but it hasn't mentioned why is this strict requirement really needed. The code was handling an allocation failure and propagated it properly up the callchain so it is not clear why it is needed. Dave has clarified the intention when I tried to remove the flag as not being necessary: " It is a serious failure. If we miss an MDESC update due to this allocation failure, the update is not an event which gets retransmitted so we will lose the updated machine description forever. We really need this allocation to succeed. " So add a comment to clarify the nofail flag and get rid of the failure check because __GFP_NOFAIL allocation doesn't fail. Signed-off-by: Michal Hocko --- arch/sparc/kernel/mdesc.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c index 99632a87e697..26c80e18d7b1 100644 --- a/arch/sparc/kernel/mdesc.c +++ b/arch/sparc/kernel/mdesc.c @@ -130,26 +130,26 @@ static struct mdesc_mem_ops memblock_mdesc_ops = { static struct mdesc_handle *mdesc_kmalloc(unsigned int mdesc_size) { unsigned int handle_size; + struct mdesc_handle *hp; + unsigned long addr; void *base; handle_size = (sizeof(struct mdesc_handle) - sizeof(struct mdesc_hdr) + mdesc_size); + /* + * Allocation has to succeed because mdesc update would be missed + * and such events are not retransmitted. + */ base = kmalloc(handle_size + 15, GFP_KERNEL | __GFP_NOFAIL); - if (base) { - struct mdesc_handle *hp; - unsigned long addr; - - addr = (unsigned long)base; - addr = (addr + 15UL) & ~15UL; - hp = (struct mdesc_handle *) addr; + addr = (unsigned long)base; + addr = (addr + 15UL) & ~15UL; + hp = (struct mdesc_handle *) addr; - mdesc_handle_init(hp, handle_size, base); - return hp; - } + mdesc_handle_init(hp, handle_size, base); - return NULL; + return hp; } static void mdesc_kfree(struct mdesc_handle *hp)