From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70DC9C433EF for ; Mon, 31 Jan 2022 10:31:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D99076B0071; Mon, 31 Jan 2022 05:31:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D49136B0073; Mon, 31 Jan 2022 05:31:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C37B26B0074; Mon, 31 Jan 2022 05:31:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id B3D2D6B0071 for ; Mon, 31 Jan 2022 05:31:43 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 59D63182067A8 for ; Mon, 31 Jan 2022 10:31:43 +0000 (UTC) X-FDA: 79090216086.16.95E48C6 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf14.hostedemail.com (Postfix) with ESMTP id B0B28100007 for ; Mon, 31 Jan 2022 10:31:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643625102; x=1675161102; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=eGahUJSlFzxGqkP2PYspVj5bNJbqX3IGWEq9Q9r47kU=; b=K89rNlKlP59M08NImK5O0rXNaS+bgiUfjwDQ/pju1wnf+fuHTFE4TfDi XxCaWF2fAQR9XslbXW6m/HML7zVSImz9yziXnLEyy9zRUGES5pECoZNia kTz6g4hGKB/Ool6tzIJU+bINuIPu800w6C8ay/SYvLiD5F2RbZJdZ1JGk bp4MCkr/4GSQXapK2lkA/YlYQaVRbU8X+i6p/2ChvPyD660F6C7PtwU4L WkamSy0IMfxcCU8Yvis2bguRPGP+DkLCHhRw5FqG9MEiOTMhD72dQ7WDm zUl5LZMYzhtCh3UC1cpyxo5+u4D3F4Z33Iw0p5UxNbyrP5Hq8jEEbXphZ w==; X-IronPort-AV: E=McAfee;i="6200,9189,10243"; a="333792771" X-IronPort-AV: E=Sophos;i="5.88,330,1635231600"; d="scan'208";a="333792771" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 02:31:41 -0800 X-IronPort-AV: E=Sophos;i="5.88,330,1635231600"; d="scan'208";a="564934983" Received: from smile.fi.intel.com ([10.237.72.61]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 02:31:37 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nETxB-00GpRd-HC; Mon, 31 Jan 2022 12:30:33 +0200 Date: Mon, 31 Jan 2022 12:30:33 +0200 From: Andy Shevchenko To: David Rientjes Cc: Waiman Long , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Rasmus Villemoes , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Ira Weiny , Rafael Aquini Subject: Re: [PATCH v2 1/3] lib/vsprintf: Avoid redundant work with 0 size Message-ID: References: <20220129205315.478628-1-longman@redhat.com> <20220129205315.478628-2-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Rspam-User: nil X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B0B28100007 X-Stat-Signature: jx4f776yk8xztycjx61cyyoxnegtx6fc Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=K89rNlKl; spf=none (imf14.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=andriy.shevchenko@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1643625102-967915 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 31, 2022 at 12:25:09PM +0200, Andy Shevchenko wrote: > On Sun, Jan 30, 2022 at 12:49:37PM -0800, David Rientjes wrote: > > On Sat, 29 Jan 2022, Waiman Long wrote: > > > > > For *scnprintf(), vsnprintf() is always called even if the input size is > > > 0. That is a waste of time, so just return 0 in this case. > > Why do you think it's not legit? I have to elaborate. For *nprintf() the size=0 is quite useful to have. For *cnprintf() the size=0 makes less sense, but, if we read `man snprintf()`: The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')). If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. (See also below under NOTES.) If an output error is encountered, a negative value is returned. Note the last sentence there. You need to answer to it in the commit message why your change is okay and it will show that you thought through all possible scenarios. -- With Best Regards, Andy Shevchenko