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 22EDDC433F5 for ; Mon, 31 Jan 2022 11:02:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A74D6B0071; Mon, 31 Jan 2022 06:02:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9562F6B0073; Mon, 31 Jan 2022 06:02:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 821916B0074; Mon, 31 Jan 2022 06:02:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id 708B66B0071 for ; Mon, 31 Jan 2022 06:02:33 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 391DA98C1F for ; Mon, 31 Jan 2022 11:02:33 +0000 (UTC) X-FDA: 79090293786.30.4CFBF60 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf04.hostedemail.com (Postfix) with ESMTP id 9406540011 for ; Mon, 31 Jan 2022 11:02:32 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id p27so26081358lfa.1 for ; Mon, 31 Jan 2022 03:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=czeOm2pkfIYtlH8bieE/wFkWMyQace30JcDwxXQeWDY=; b=NAM+paj077GlbsSEbAhREf9Ku6Zelpm258xyJs/uNE2AuRvKnCy48gfwZAgwyslTFR m3FwDtohPmEJwRAkIVNJawuANbhmN7JaxgRofyQ/AdWTlQb60iLuWwhb63Vy8Kso+QP0 7e2+p6p/6JWa/AfN5eIUs1nzVxb1IJYuYjzQA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=czeOm2pkfIYtlH8bieE/wFkWMyQace30JcDwxXQeWDY=; b=015rjUtGWDUqkuTNQMBez3QBQIDEpX8NnnkiUyuWx5P/YQhLXyLLLYq8TlLu6Kwslt k4hFOnM6+nK170mbvpCHrQvA5X+bDDWEfo7PlJdS23G57OeLFxvvSA8HpFPqc7imjW9I GXe0dc6J/MwxCvahctCXHtsFyECwb+fsjLtxre4zhhS13qY/XyRtKXzPKuHYCR2DGCIQ mmY1myf/GaONxZ8txqZBeUdp+A2sWfGhtfwHrmWTXNRxFRuQeb83JoECIzXziWbVXFH1 avErvxfa/mARdPPiKz5dktzdr1vsCVJPpvp10FgFcsq8Ou9ldVm3mGEZtBA1OtUor1Cd Ui/w== X-Gm-Message-State: AOAM531FOnKpkrlTL8ZZWKjgPDFZoP+GDixhLLi9ggeeBnj7BdZ2ztSk Q+YtOP58XeELUXo9GekqEphN9Q== X-Google-Smtp-Source: ABdhPJz1ok/mMVMmC6806RcAq8MH2XjtwH5h47J/+uzZ8Kh+q34vMsAK2Yo0+uhGrtutG1qy+aMGMg== X-Received: by 2002:a05:6512:12c5:: with SMTP id p5mr16013020lfg.89.1643626951003; Mon, 31 Jan 2022 03:02:31 -0800 (PST) Received: from [172.16.11.74] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id g7sm1962543ljk.83.2022.01.31.03.02.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jan 2022 03:02:30 -0800 (PST) Subject: Re: [PATCH v2 1/3] lib/vsprintf: Avoid redundant work with 0 size To: Andy Shevchenko , David Rientjes Cc: Waiman Long , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Ira Weiny , Rafael Aquini References: <20220129205315.478628-1-longman@redhat.com> <20220129205315.478628-2-longman@redhat.com> From: Rasmus Villemoes Message-ID: Date: Mon, 31 Jan 2022 12:02:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 9406540011 X-Stat-Signature: o9ut9fn5fcurep93dsuwwhcwtttxd7t8 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=NAM+paj0; dmarc=none; spf=pass (imf04.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.167.45 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk X-Rspam-User: nil X-HE-Tag: 1643626952-915008 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 31/01/2022 11.34, Andy Shevchenko wrote: > On Mon, Jan 31, 2022 at 12:30:33PM +0200, Andy Shevchenko wrote: >> 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. > > Also it seems currently the kernel documentation is not aligned with the code > > "If @size is == 0 the function returns 0." > > It should mention the (theoretical?) possibility of getting negative value, > if vsnprintf() returns negative value. > The kernel's vsnprintf _will never_ return a negative value. There is way too much code which relies on that. It also has to work from any context, so we'll never do any memory allocation or anything else that could possibly force us to error out, and even if we encounter some impossible situation, we do not return a negative value, but just stop the output where we are. So yes, micro-optimizing [v]scnprintf() is completely valid, but I've never bothered to send the patch because the use case for scnprintf() is primarily the ret += scnprintf(buf + ret, size - ret, ...); pattern, with ret starting out at 0 and size being some non-zero number. When given a non-zero size, scnprintf() is guaranteed to return something _strictly less_ than that value; that invariant guarantees that the size-ret expression never becomes 0. So if scnprintf() is properly used, I can't think of any situation where size will be 0, hence I see that patch as correct-but-mostly-pointless. Rasmus