Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3472974imu; Fri, 30 Nov 2018 00:30:54 -0800 (PST) X-Google-Smtp-Source: AFSGD/W0KU86OlK5i43dTYUB11NsIJ8aXUk2vKV5XhMoVGFUqcDuaCeMcljlR6djMkxg4gFd4JR3 X-Received: by 2002:a17:902:7c85:: with SMTP id y5mr4743366pll.63.1543566654134; Fri, 30 Nov 2018 00:30:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543566654; cv=none; d=google.com; s=arc-20160816; b=TOYeW/ZhNRYVixzIiGqr5zdkCfh3j9i/nIDmf1wjcLn+T+U9VdlnomdTxqNL6czo0+ WyVq7rHjN8+sQzApwdivH6iNEXwhJqLbCgCt6G5UUcLORdFxZ1jMYhgy6zYdeqNW8c8h RpSKwEda9MCmKO+Hz0SsZHFpS4rIz8+On6WG3xPRsXkm1axtKzAKmE1GcrWfJjRu9sia z/6pgQObQIq505tsMzIFjBQjOjm/Z3BM+HFquYMgq/XQSweZbe6q2HFYYTXj/Gh8rvRH XHhluR6g/lROm4o9yZyswuPdR6TGxuBdBzm1WhckBkaIYIibVoqotX5v4X5owuNtuFoE Qedg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=xB7HdDFQ764btLMy306UN4ZvjvdbKNIVFgwF0DdJUQo=; b=Ib+kVWPnQpduSR6p5U5al8piNVIcoQ1OUTfOG28RCX3Y+iNKuAXB6UJSyoCCtCcqA0 81bcmnc7aIHbhYxlP31RFVOlldaf7FgY74dL3MTi4vAcXQu3bahNFqn3gFFoNgOxykd4 qHrJov91tKm/0KIJxwk41AVAVOniuSs3M71FME+YepRfsSBDig6svot8j0UGqVs0FEcN nRud8WwWRbCzMSgK/ZZ+cB2HM2Qsxes96GfQ/aF89XkSJhJVRmmlsqLTgOcXQpgI4rcA Jm1uC6EotpGeOUqXaMPpPEZO4ss+Ds2854zJHhAz0PKoNOzH5kERT56hwBpcsh41PsUK 89dQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3si4301209pgh.496.2018.11.30.00.30.38; Fri, 30 Nov 2018 00:30:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726843AbeK3Tie (ORCPT + 99 others); Fri, 30 Nov 2018 14:38:34 -0500 Received: from 178.115.242.59.static.drei.at ([178.115.242.59]:35131 "EHLO mail.osadl.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726651AbeK3Tie (ORCPT ); Fri, 30 Nov 2018 14:38:34 -0500 Received: by mail.osadl.at (Postfix, from userid 1001) id 459705C09BF; Fri, 30 Nov 2018 08:29:26 +0000 (UTC) Date: Fri, 30 Nov 2018 09:29:26 +0100 From: Nicholas Mc Guire To: Stephen Boyd Cc: Michael Turquette , Nicholas Mc Guire , Michal Simek , Rob Herring , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2] clk: zynq: do not allow kmalloc failure Message-ID: <20181130082926.GA6517@osadl.at> References: <1542803310-32673-1-git-send-email-hofrat@osadl.org> <154353512315.88331.4548631955021366823@swboyd.mtv.corp.google.com> <20181130075453.GB2456@osadl.at> <154356537055.88331.12823387821854167503@swboyd.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <154356537055.88331.12823387821854167503@swboyd.mtv.corp.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 30, 2018 at 12:09:30AM -0800, Stephen Boyd wrote: > Quoting Nicholas Mc Guire (2018-11-29 23:54:53) > > On Thu, Nov 29, 2018 at 03:45:23PM -0800, Stephen Boyd wrote: > > > Quoting Nicholas Mc Guire (2018-11-21 04:28:30) > > > > The kmalloc here is small (< 16 bytes) and occurs during initialization > > > > during system startup here (can not be built as module) thus if this > > > > kmalloc failed it is an indication of something more serious going on > > > > and it is fine to hang the system here rather than cause some harder > > > > to understand error by dereferencing NULL. > > > > > > > > Explicitly checking would not make that much sense here as the only > > > > possible reaction would be would BUG() here anyway. > > > > > > > > Signed-off-by: Nicholas Mc Guire > > > > Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver") > > > > Acked-by: Michal Simek > > > > --- > > > > > > Nak. We don't have any __GFP_NOFAIL in drivers/clk and I don't see a > > > reason why we would want it here either. Just handle the failure, or > > > don't care if this is so critical to system boot. > > > > > It was not motivated by the criticality but by the low probability > > and cluttering the code for this case did not seem good to me. > > Effectively handling it here means BUG() - so more or less > > the same result that hanging it on __GFP_NOFAIL if allocation > > was not possible would cause. > > > > Not clear what the objection to __GFP_NOFAIL here is - my understanding > > was that it is intended precisely for cases like this - but > > I?ll send a V2 handling it with BUG_ON(!clk_name) if that is prefered. > > > > Or just WARN() and return. Maybe something else can get far enough to be > helpful. > > I would also appreciate if this sort of problem could be caught earlier > in code review and/or with some automated scripting. Debating BUG_ON() > and allocation failures is not what I look forward to doing so please > try to make this exact sort of patch never make it to the list in the > first place. > well it was found by a experimental coccinelle script I?m trying to write up semi-formal specifications for APIs so that this can be tested automatically and cought early. If you put in a WARN() here it would still allow for the NULL pointer to be passt on potentially corupting memory in the following snprintf()->vsnprintf() which does not seem to check for !buf thx! hofrat