Received: by 10.223.185.116 with SMTP id b49csp5159702wrg; Tue, 27 Feb 2018 08:41:29 -0800 (PST) X-Google-Smtp-Source: AH8x225t+SMjjbLaLEmxTsXl0zD+m/EDxv1dHborcmm8OIqBdDUA84bKesUpVEEos1NgkrTDZQuU X-Received: by 2002:a17:902:50e:: with SMTP id 14-v6mr14755084plf.360.1519749689134; Tue, 27 Feb 2018 08:41:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519749689; cv=none; d=google.com; s=arc-20160816; b=B+GZbkp3B3tFMY67Zxfc+ezR8LYpMXGkzHWHRs6IfkwGnf58HpqsbxUV9U0yd2GyME 11CaQEKdot9sUsqGTOsgT1JcHSfXCrAT1BP0S7cKIBHvsTJw8UpSmXzW+uC+8Xc4neRU lT5/fXqEcc4R6zs9VcuPLsuXNPX9+AHVA3nO8UTBBs+iOHTIMD/3IulziQxGXqDF0ywC ht39RSli8sFqN4sbX3XqZmzEg5BCLXTdJaK+4PXQY8P0CQK75fdzrFFypUkdNqSP3v1v H3M5IKHnk6MmNRkYXtnfHoRQc2y7GrP5+3aUgciF0uRk+/GxYK2DKRS3jZbkWDqVAXbR KQQg== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=0FbRkLDczYhLYf01mHvuupdIU3YWI234mLagLxUC5K0=; b=p9Nr1PEYPmfT0hHtcUFclSv1OJkaaV22YQahmYNqeKu7xGUvsHAKTLYPV3spQpcsnX JodEbvggZH4tfGa7NQ6OgexBKEj0NyXdCZsNiR7uh8UNO1YnKeLcPBaKBW7weYcV08ys WAFMJuVV0T8kLmcOqSGM4olq2QHiZ7uSlkaEABdUh1eQmSsdOz9R+J0GnoUCIN+eMhQz wW3xY0hBEwNDHQQpbotTtL1z0M92khnZHKq8ECAX5C7QY2TaDxoNPXCxliDjM3n5WkFo vxKpW4jk7PTcl19HgJ6IVtVoO6BYYJmJOa9JTwLvyYxtS2TLxIL+WmVoFRNe6B2vJ9k8 h5Pw== 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 c8-v6si9102200plm.9.2018.02.27.08.41.14; Tue, 27 Feb 2018 08:41:29 -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 S1754032AbeB0Puv (ORCPT + 99 others); Tue, 27 Feb 2018 10:50:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:40623 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753264AbeB0Puu (ORCPT ); Tue, 27 Feb 2018 10:50:50 -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 28AD4AD03; Tue, 27 Feb 2018 15:50:49 +0000 (UTC) Date: Tue, 27 Feb 2018 16:50:47 +0100 From: Petr Mladek To: Andy Shevchenko Cc: "Tobin C . Harding" , linux@rasmusvillemoes.dk, Joe Perches , linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko Subject: Re: [PATCH v2 8/9] lib/vsprintf: Remove useless NULL checks Message-ID: <20180227155047.o74ohmoyj56up6pa@pathway.suse.cz> References: <20180216210711.79901-1-andriy.shevchenko@linux.intel.com> <20180216210711.79901-8-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180216210711.79901-8-andriy.shevchenko@linux.intel.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2018-02-16 23:07:10, Andy Shevchenko wrote: > The pointer can't be NULL since it's first what has been done in the > pointer(). > > Remove useless checks. > > Note we leave check for !CONFIG_HAVE_CLK to make compiler > to optimize code away when possible. > > Cc: Petr Mladek > Signed-off-by: Andy Shevchenko > --- > lib/vsprintf.c | 13 +------------ > 1 file changed, 1 insertion(+), 12 deletions(-) > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 97be2d07297a..a49da00b79e7 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -819,10 +819,6 @@ char *hex_string(char *buf, char *end, u8 *addr, struct printf_spec spec, > /* nothing to print */ > return buf; > > - if (ZERO_OR_NULL_PTR(addr)) This macro matches also values <= 16. All these values are handled as NULL by kfree(). Therefore it would make sense to write "(null)" for them. But pointer() prints "(null)" only for ptr == 0. See below. > - /* NULL pointer */ > - return string(buf, end, NULL, spec); > - > switch (fmt[1]) { > case 'C': > separator = ':'; > @@ -1258,10 +1254,6 @@ char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec, > if (spec.field_width == 0) > return buf; /* nothing to print */ > > - if (ZERO_OR_NULL_PTR(addr)) > - return string(buf, end, NULL, spec); /* NULL pointer */ > - > - > do { > switch (fmt[count++]) { > case 'a': > @@ -1455,7 +1447,7 @@ static noinline_for_stack > char *clock(char *buf, char *end, struct clk *clk, struct printf_spec spec, > const char *fmt) > { > - if (!IS_ENABLED(CONFIG_HAVE_CLK) || !clk) > + if (!IS_ENABLED(CONFIG_HAVE_CLK)) > return string(buf, end, NULL, spec); > > switch (fmt[1]) { > @@ -1580,9 +1572,6 @@ char *device_node_string(char *buf, char *end, struct device_node *dn, > if (!IS_ENABLED(CONFIG_OF)) > return string(buf, end, "(!OF)", spec); > > - if ((unsigned long)dn < PAGE_SIZE) > - return string(buf, end, "(null)", spec); In this case, "null" was printed for ptr < PAGE_SIZE. The same check is also in string() function. Note that it is not only about the printed value. The pointer is later derefecend. We will start crashing on dn > 0 && dn < PAGE_SIZE. To be honest, I do not feel experienced enough to decide about the preferred behavior. On one hand, it is bad when printk() would crash the kernel. On the other hand, hiding wide range of values under "(null)" string might confuse people. Would it make sense to survive and write different strings for difference intervals? For example? "(null)" for ptr == 0 "(null-16)" for ptr > 0 && ptr <= 16 "(null-pg)" for prt > 16 && ptr <= PAGE_SIZE In each case, this patch changes the behavior and it should be documented in the commit message. Best Regards, Petr