Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp901567pxb; Tue, 1 Feb 2022 12:47:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJykX2o45z73tI0+Nv/PVSkY9EGrqJ27/pRFxDnvykiRkFc8daTCwXeXavInTidCEvKNnTeu X-Received: by 2002:a63:8649:: with SMTP id x70mr21892545pgd.564.1643748458654; Tue, 01 Feb 2022 12:47:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643748458; cv=none; d=google.com; s=arc-20160816; b=NdGhVwKuWYsD83C8o8WSz0LfuoonrJwHIrCIaAL8UL7BKKewpLMnISoPANdq3xXmy8 vgLvdin+D9U0sK9XheC7tBa2E1D5H605MLwNZtrwXPRj8nVqEOXfM3b0tt/fmjF8L9kH BfgxqYvVUlx8E7M8yxpDEkjxJgYw/ozBhPrnIrqNHYrNBBKlJHRyCTHLf/Xr4slZJf+8 mrMEuKiuFkmJ1x5J7hIsTdpqfdzmrVd2mC58sVNsBrRhpXizjvtCSZuKGwPEIkb3YGc4 AALk1yFcDqMrfIxWyOJS0qrTB78RWP+QuOaqDVWZErPTC0uvMHI9K2wl6WDIjZ7CK8S5 iPNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=KfQFfvwTGn23fXKYlknOZjlgILY6kYRW26SfIwpEJJM=; b=c84CmPvND/MCPur7jNFlHMzeHsbIXMc+1k+TWC0PsLVSQ87Fqq4d1AnIxf7d+O7LIP +FP67C8KCRdPG7rcMqmy6bAvEdzCS0wqw/KCN6ZYA8CYZ8hYXwGRtm6JyCxFXwAq/dW2 T+Q9Xt1IisCQgyjDJ6QSVCdXS3tjrQ/CDMj8yNoCuLU75sS59ynjm+kolqv/d7MpRFsL QEkgaA/13j0NUxLU5UxH+fuxl1DRS6loFjooWnZPtK90mUAd972t2A6YpQbfIIcow6Bp KtV60KLewCIHY6HuAU4P9jYbxj+owpfOJTqDueHZDBuNaQ+u7FIEhkk5pe68xAhf4YyU vNWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HKNyrpQa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s206si6083861pgs.442.2022.02.01.12.47.27; Tue, 01 Feb 2022 12:47:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HKNyrpQa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343721AbiAaSsZ (ORCPT + 99 others); Mon, 31 Jan 2022 13:48:25 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:55806 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358298AbiAaSsT (ORCPT ); Mon, 31 Jan 2022 13:48:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643654898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KfQFfvwTGn23fXKYlknOZjlgILY6kYRW26SfIwpEJJM=; b=HKNyrpQa598Ejmi7D9BN6TnVcyRStku6wt7yQ1gZaqhWXPZHFKfCgwrrZenPiipysWdYo2 KLzIAmy25avmprcxQZ2KgIK4DcKYFWdDuPVKRmNBfY5qYvdZolXOfhFBDHrfJGbDU62BSU peapwoxB8eblWWqhICPiXNi2uMpUUCg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-354-y95AX1aoM06TnU-mvZxpgg-1; Mon, 31 Jan 2022 13:48:15 -0500 X-MC-Unique: y95AX1aoM06TnU-mvZxpgg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 566D81966320; Mon, 31 Jan 2022 18:48:13 +0000 (UTC) Received: from [10.22.16.244] (unknown [10.22.16.244]) by smtp.corp.redhat.com (Postfix) with ESMTP id A8C977A424; Mon, 31 Jan 2022 18:48:11 +0000 (UTC) Message-ID: Date: Mon, 31 Jan 2022 13:48:11 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v2 1/3] lib/vsprintf: Avoid redundant work with 0 size Content-Language: en-US To: Andy Shevchenko , David Rientjes Cc: 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 References: <20220129205315.478628-1-longman@redhat.com> <20220129205315.478628-2-longman@redhat.com> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/31/22 05: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. AFAICS, the kernel's vsnprintf() function will not return -1. So in that sense it is not fully POSIX compliant. Since vscnprintf() function always returns 0 when size is 0, there is no point in finding out exactly how much bytes the buffer needs to hold the formatted text as this information will not be returned back to the caller anyway. I will update to indicate the vsnprintf() does not return -1. Thanks, Longmn