[v2] bcachefs: Avoid a potential useless over memory allocation in bch2_prt_[v]printf()
Message ID | 4c614db674887346ea418acaeafd6bf86502ec77.1708272713.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-70438-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp848907dyc; Sun, 18 Feb 2024 08:14:01 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVUkKNS3k9KA9i9foQq/mKPJnmwuOkJ/SoRzyoQ1ZpQJ6cCCsWFTqRZASDHBARkoOwi8lD+9vPWBo3BJ21sR0Omuf5uAA== X-Google-Smtp-Source: AGHT+IFiADNgFDrYhi644ok4OstCpNCJd+XHvWNreQUkUx20wqD9ngzzcU4Xf3l9bdJyS1XcUVqW X-Received: by 2002:a17:902:6841:b0:1da:1c72:2ca7 with SMTP id f1-20020a170902684100b001da1c722ca7mr10675603pln.29.1708272841730; Sun, 18 Feb 2024 08:14:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708272841; cv=pass; d=google.com; s=arc-20160816; b=xdLhROuGU1YvAKSeIqdrQWrgXDLiSFTT24bHJkeULX+zdmuM6DY2J0xP9FbtY+baT4 JeIWUZ/nCjEfxJClyweNpCnQi6fAoZlLPP7/YSOsAlTviH762DV5S61h/+YtnUwFR7IG /9reKIraNDOfoMJbMLPY//VT7drYlp6lPcBagaoTcFpeK6lV1EQfUHjySFpitAmWuLso XGJdym2bnNU6YAyq/a0Voukm3O4Jz3J8ccHw9+4r9pBL0lnF+5tCo2A3F0tiMIQeQITT iCyLjqnYHGdQWCjkWdKQg9TC3rnvToJzqbGtmkydVs8GA+OpdntPLPtC5kpRG8xrkwOL 4FNQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=yP76YXZufoYcbf/1hIaf1uWL8S4sDWOfmF4KUI6YdvU=; fh=m3UyueLH4KDy0H9ZPaSnoQRYWYiD76Xl1Jq/Gorb8Ss=; b=0DDM2KYznf4ylRf2sBMKBG2ZYNWs5YkBXSacmp8VK/8eaiXErCBkoB0KA3eEw39B1R ohnsalPp/r44hhwduoKPVqKpbDdC0MSauLUGPgc4b7i54+FNLdJ63m+1T6jXAClWpa85 r/MwxsFE42xTzzRnkxguaa5NoX25JyZAIaJ1HbkQ1Zy4D5jfpvrfh8gAqdPj8/CaM56E dlfxev8JGWH+RX0CbLKMa5VmNZ+YyWTpY406F9intedzfm7YFtQAHJAMY8WLKXklj36d 2SfiI1Dxz6blRhOjJjI+7X7XomYCloqYjUVdyVRaPZjO61sU2yiGus25iMPq+L66laC0 eegw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=JHaOFZbA; arc=pass (i=1 spf=pass spfdomain=wanadoo.fr dkim=pass dkdomain=wanadoo.fr dmarc=pass fromdomain=wanadoo.fr); spf=pass (google.com: domain of linux-kernel+bounces-70438-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70438-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id n17-20020a170902e55100b001db7d2a8cb5si3150088plf.437.2024.02.18.08.14.01 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Feb 2024 08:14:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-70438-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=JHaOFZbA; arc=pass (i=1 spf=pass spfdomain=wanadoo.fr dkim=pass dkdomain=wanadoo.fr dmarc=pass fromdomain=wanadoo.fr); spf=pass (google.com: domain of linux-kernel+bounces-70438-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70438-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 8A6E4281835 for <ouuuleilei@gmail.com>; Sun, 18 Feb 2024 16:14:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 881E46D1D3; Sun, 18 Feb 2024 16:13:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wanadoo.fr header.i=@wanadoo.fr header.b="JHaOFZbA" Received: from smtp.smtpout.orange.fr (smtp-15.smtpout.orange.fr [80.12.242.15]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 20E886D1BE for <linux-kernel@vger.kernel.org>; Sun, 18 Feb 2024 16:13:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.12.242.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708272830; cv=none; b=k845zrWG7Q8UHz4a4vUGG1YKTlk9mZsaw4BEXyzPSZuhef3QVhOdpNlpmTE5MyeVFFzsJmK+QeCNVIIAhTNF47Wql9NxrH/8hZYQT1HZJPGLw4eJUp7+PV1JlE/9hJ62OuvHtwsiQuomElrUkNcU4Y0GDPjTzVovLZDd0uLSlBo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708272830; c=relaxed/simple; bh=bbVXN7nFPxD2+8T/Qp3xY6pFsgPWqO0g3GtqcUTohS4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=SLtOjaCZfvf9wLlMfpjwjNhr38t6O4EpkF/0cAd40vAvfBEojEZdApD5wUlqM0i3Nz9Vnk188x9yI5Nx3M+VYAv5UZP/78ztafZwm4VODL19gsbJYmZc15OPeoGEBBpz9uV2QqSKmK8bNYi7j/+zlScjS/5sncnC9z1h7HV060k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wanadoo.fr; spf=pass smtp.mailfrom=wanadoo.fr; dkim=pass (2048-bit key) header.d=wanadoo.fr header.i=@wanadoo.fr header.b=JHaOFZbA; arc=none smtp.client-ip=80.12.242.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wanadoo.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wanadoo.fr Received: from fedora.home ([92.140.202.140]) by smtp.orange.fr with ESMTPA id bjmLrpU1LVqNHbjmLrVuBk; Sun, 18 Feb 2024 17:12:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1708272754; bh=yP76YXZufoYcbf/1hIaf1uWL8S4sDWOfmF4KUI6YdvU=; h=From:To:Cc:Subject:Date; b=JHaOFZbAvu0zG1EvsB/x423fdxAWjYdx+Flpo+0ruoCfh8f0EnbAsRDDWzio52hMD gqImRib0PIjw31bAQaABDabNQjHimRkR1HYvo1VOtSQkqpSHWXo7t9sFmscYKOBZP5 9mtdG71zMCFgwKWJEj687d9tdx4+uqqidiCAa0SCrczJ8e9oI+gVPA/zQTg9XGfU64 bTOlvP3vYm3zvCE3LqOCH1LLeYL+Wh8iZXftj8dNT+YUQO36EHtMhGMGFgQeaOZ6w7 MmQClqXECsTRopQXvfGmb4gNNJM5d4g8Lr4eBtD2GFzTxL9YCvMpDEcSxWfksBW3V4 e7Z5HvIfNy0GQ== X-ME-Helo: fedora.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Sun, 18 Feb 2024 17:12:34 +0100 X-ME-IP: 92.140.202.140 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: Kent Overstreet <kent.overstreet@linux.dev>, Brian Foster <bfoster@redhat.com> Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, linux-bcachefs@vger.kernel.org Subject: [PATCH v2] bcachefs: Avoid a potential useless over memory allocation in bch2_prt_[v]printf() Date: Sun, 18 Feb 2024 17:12:28 +0100 Message-ID: <4c614db674887346ea418acaeafd6bf86502ec77.1708272713.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.43.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791253902798438461 X-GMAIL-MSGID: 1791253902798438461 |
Series |
[v2] bcachefs: Avoid a potential useless over memory allocation in bch2_prt_[v]printf()
|
|
Commit Message
Christophe JAILLET
Feb. 18, 2024, 4:12 p.m. UTC
2 issues related to incorrect available space in the output buffer
computation may lead to some extra memory allocation.
First: vsnprintf() takes the size of the buffer, *including* the space for
the trailing null.
But printbuf_remaining() returns the number of characters we can print
to the output buffer, *excluding* the terminating null.
So, use printbuf_remaining_size(), which includes the space for the
terminating null.
Second: if the return value of vsnprintf() is greater than or equal to the
passed size, the resulting string is truncated.
So, in order to see if some extra space is needed, the check needs to be
changed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Un-tested
v2: - Use printbuf_remaining_size() instead of hand-writing it. [Brian Foster]
- Reword the commit log, hoping it is clearer.
- Synch with -next-20240215
v1: https://lore.kernel.org/all/0f40108bed3e084057223bdbe32c4b37f8500ff3.1694845203.git.christophe.jaillet@wanadoo.fr/
---
fs/bcachefs/printbuf.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Comments
On Sun, Feb 18, 2024 at 05:12:28PM +0100, Christophe JAILLET wrote: > 2 issues related to incorrect available space in the output buffer > computation may lead to some extra memory allocation. > > > First: vsnprintf() takes the size of the buffer, *including* the space for > the trailing null. > > But printbuf_remaining() returns the number of characters we can print > to the output buffer, *excluding* the terminating null. > > So, use printbuf_remaining_size(), which includes the space for the > terminating null. > > > Second: if the return value of vsnprintf() is greater than or equal to the > passed size, the resulting string is truncated. > So, in order to see if some extra space is needed, the check needs to be > changed. > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Thanks, applied
On Sun, Feb 18, 2024 at 05:12:28PM +0100, Christophe JAILLET wrote: > 2 issues related to incorrect available space in the output buffer > computation may lead to some extra memory allocation. > > > First: vsnprintf() takes the size of the buffer, *including* the space for > the trailing null. > > But printbuf_remaining() returns the number of characters we can print > to the output buffer, *excluding* the terminating null. > > So, use printbuf_remaining_size(), which includes the space for the > terminating null. nope, buggy. passing printbuf_remaining_size() to snprintf() is correct, but snprintf() returns the number of charecters wrote _excluding_ the null > > > Second: if the return value of vsnprintf() is greater than or equal to the > passed size, the resulting string is truncated. > So, in order to see if some extra space is needed, the check needs to be > changed. > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > Un-tested > > v2: - Use printbuf_remaining_size() instead of hand-writing it. [Brian Foster] > - Reword the commit log, hoping it is clearer. > - Synch with -next-20240215 > > v1: https://lore.kernel.org/all/0f40108bed3e084057223bdbe32c4b37f8500ff3.1694845203.git.christophe.jaillet@wanadoo.fr/ > --- > fs/bcachefs/printbuf.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/fs/bcachefs/printbuf.c b/fs/bcachefs/printbuf.c > index b27d22925929..8cee9c2f88c4 100644 > --- a/fs/bcachefs/printbuf.c > +++ b/fs/bcachefs/printbuf.c > @@ -55,9 +55,10 @@ void bch2_prt_vprintf(struct printbuf *out, const char *fmt, va_list args) > va_list args2; > > va_copy(args2, args); > - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args2); > + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), > + fmt, args2); > va_end(args2); > - } while (len + 1 >= printbuf_remaining(out) && > + } while (len >= printbuf_remaining_size(out) && > !bch2_printbuf_make_room(out, len + 1)); > > len = min_t(size_t, len, > @@ -72,9 +73,10 @@ void bch2_prt_printf(struct printbuf *out, const char *fmt, ...) > > do { > va_start(args, fmt); > - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args); > + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), > + fmt, args); > va_end(args); > - } while (len + 1 >= printbuf_remaining(out) && > + } while (len >= printbuf_remaining_size(out) && > !bch2_printbuf_make_room(out, len + 1)); > > len = min_t(size_t, len, > -- > 2.43.2 >
On Sun, Feb 18, 2024 at 05:12:28PM +0100, Christophe JAILLET wrote: > 2 issues related to incorrect available space in the output buffer > computation may lead to some extra memory allocation. > > > First: vsnprintf() takes the size of the buffer, *including* the space for > the trailing null. > > But printbuf_remaining() returns the number of characters we can print > to the output buffer, *excluding* the terminating null. > > So, use printbuf_remaining_size(), which includes the space for the > terminating null. > > > Second: if the return value of vsnprintf() is greater than or equal to the > passed size, the resulting string is truncated. > So, in order to see if some extra space is needed, the check needs to be > changed. btw, the patch was suspect to begin with in cases where off-by-one errors are difficult to avoid, but harmless in one direction - just over allocate.
Le 19/02/2024 à 04:39, Kent Overstreet a écrit : > On Sun, Feb 18, 2024 at 05:12:28PM +0100, Christophe JAILLET wrote: >> 2 issues related to incorrect available space in the output buffer >> computation may lead to some extra memory allocation. >> >> >> First: vsnprintf() takes the size of the buffer, *including* the space for >> the trailing null. >> >> But printbuf_remaining() returns the number of characters we can print >> to the output buffer, *excluding* the terminating null. >> >> So, use printbuf_remaining_size(), which includes the space for the >> terminating null. > > nope, buggy. > > passing printbuf_remaining_size() to snprintf() is correct, but > snprintf() returns the number of charecters wrote _excluding_ the null Hi, I think that the patch is correct. snprintf() returns the number of characters wrote _excluding_ the null. That is why the test is: len >= size_of_the_buffer ==> more space is needed. The case you describe is handled by the == part of >=. On the contrary, if len is < size_of_the_buffer, then we have at least 1 place for the terminating NULL. It will then eventually lead to: len_of_the_string + space_for_'\0' == size_of_the_buffer So it does not overflow. Anyway, feel free to ignore the patch completely if it sounds too risky, take only half of it (s/printbuf_remaining/printbuf_remaining_size/) if you are more confident with it, or the complete patch if the explanation above convinced you. From my PoV, the 3 options lead to the same run-time output, with more or less memory allocated. Best regards. CJ > >> >> >> Second: if the return value of vsnprintf() is greater than or equal to the >> passed size, the resulting string is truncated. >> So, in order to see if some extra space is needed, the check needs to be >> changed. >> >> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> >> --- >> Un-tested >> >> v2: - Use printbuf_remaining_size() instead of hand-writing it. [Brian Foster] >> - Reword the commit log, hoping it is clearer. >> - Synch with -next-20240215 >> >> v1: https://lore.kernel.org/all/0f40108bed3e084057223bdbe32c4b37f8500ff3.1694845203.git.christophe.jaillet@wanadoo.fr/ >> --- >> fs/bcachefs/printbuf.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/fs/bcachefs/printbuf.c b/fs/bcachefs/printbuf.c >> index b27d22925929..8cee9c2f88c4 100644 >> --- a/fs/bcachefs/printbuf.c >> +++ b/fs/bcachefs/printbuf.c >> @@ -55,9 +55,10 @@ void bch2_prt_vprintf(struct printbuf *out, const char *fmt, va_list args) >> va_list args2; >> >> va_copy(args2, args); >> - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args2); >> + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), >> + fmt, args2); >> va_end(args2); >> - } while (len + 1 >= printbuf_remaining(out) && >> + } while (len >= printbuf_remaining_size(out) && >> !bch2_printbuf_make_room(out, len + 1)); >> >> len = min_t(size_t, len, >> @@ -72,9 +73,10 @@ void bch2_prt_printf(struct printbuf *out, const char *fmt, ...) >> >> do { >> va_start(args, fmt); >> - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args); >> + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), >> + fmt, args); >> va_end(args); >> - } while (len + 1 >= printbuf_remaining(out) && >> + } while (len >= printbuf_remaining_size(out) && >> !bch2_printbuf_make_room(out, len + 1)); >> >> len = min_t(size_t, len, >> -- >> 2.43.2 >> > >
On Mon, Feb 19, 2024 at 07:10:10PM +0100, Christophe JAILLET wrote: > Le 19/02/2024 à 04:39, Kent Overstreet a écrit : > > On Sun, Feb 18, 2024 at 05:12:28PM +0100, Christophe JAILLET wrote: > > > 2 issues related to incorrect available space in the output buffer > > > computation may lead to some extra memory allocation. > > > > > > > > > First: vsnprintf() takes the size of the buffer, *including* the space for > > > the trailing null. > > > > > > But printbuf_remaining() returns the number of characters we can print > > > to the output buffer, *excluding* the terminating null. > > > > > > So, use printbuf_remaining_size(), which includes the space for the > > > terminating null. > > > > nope, buggy. > > > > passing printbuf_remaining_size() to snprintf() is correct, but > > snprintf() returns the number of charecters wrote _excluding_ the null > > Hi, > > I think that the patch is correct. You didn't test it, I did. In the future, no more patches that you haven't tested - thanks. > snprintf() returns the number of characters wrote _excluding_ the null. That > is why the test is: len >= size_of_the_buffer ==> more space is needed. > The case you describe is handled by the == part of >=. > > On the contrary, if len is < size_of_the_buffer, then we have at least 1 > place for the terminating NULL. It will then eventually lead to: > len_of_the_string + space_for_'\0' == size_of_the_buffer > So it does not overflow. > > > Anyway, feel free to ignore the patch completely if it sounds too risky, > take only half of it (s/printbuf_remaining/printbuf_remaining_size/) if you > are more confident with it, or the complete patch if the explanation above > convinced you. > > From my PoV, the 3 options lead to the same run-time output, with more or > less memory allocated. > > Best regards. > > CJ > > > > > > > > > > > > > Second: if the return value of vsnprintf() is greater than or equal to the > > > passed size, the resulting string is truncated. > > > So, in order to see if some extra space is needed, the check needs to be > > > changed. > > > > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > --- > > > Un-tested > > > > > > v2: - Use printbuf_remaining_size() instead of hand-writing it. [Brian Foster] > > > - Reword the commit log, hoping it is clearer. > > > - Synch with -next-20240215 > > > > > > v1: https://lore.kernel.org/all/0f40108bed3e084057223bdbe32c4b37f8500ff3.1694845203.git.christophe.jaillet@wanadoo.fr/ > > > --- > > > fs/bcachefs/printbuf.c | 10 ++++++---- > > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > > > diff --git a/fs/bcachefs/printbuf.c b/fs/bcachefs/printbuf.c > > > index b27d22925929..8cee9c2f88c4 100644 > > > --- a/fs/bcachefs/printbuf.c > > > +++ b/fs/bcachefs/printbuf.c > > > @@ -55,9 +55,10 @@ void bch2_prt_vprintf(struct printbuf *out, const char *fmt, va_list args) > > > va_list args2; > > > va_copy(args2, args); > > > - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args2); > > > + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), > > > + fmt, args2); > > > va_end(args2); > > > - } while (len + 1 >= printbuf_remaining(out) && > > > + } while (len >= printbuf_remaining_size(out) && > > > !bch2_printbuf_make_room(out, len + 1)); > > > len = min_t(size_t, len, > > > @@ -72,9 +73,10 @@ void bch2_prt_printf(struct printbuf *out, const char *fmt, ...) > > > do { > > > va_start(args, fmt); > > > - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args); > > > + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), > > > + fmt, args); > > > va_end(args); > > > - } while (len + 1 >= printbuf_remaining(out) && > > > + } while (len >= printbuf_remaining_size(out) && > > > !bch2_printbuf_make_room(out, len + 1)); > > > len = min_t(size_t, len, > > > -- > > > 2.43.2 > > > > > > > >
diff --git a/fs/bcachefs/printbuf.c b/fs/bcachefs/printbuf.c index b27d22925929..8cee9c2f88c4 100644 --- a/fs/bcachefs/printbuf.c +++ b/fs/bcachefs/printbuf.c @@ -55,9 +55,10 @@ void bch2_prt_vprintf(struct printbuf *out, const char *fmt, va_list args) va_list args2; va_copy(args2, args); - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args2); + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), + fmt, args2); va_end(args2); - } while (len + 1 >= printbuf_remaining(out) && + } while (len >= printbuf_remaining_size(out) && !bch2_printbuf_make_room(out, len + 1)); len = min_t(size_t, len, @@ -72,9 +73,10 @@ void bch2_prt_printf(struct printbuf *out, const char *fmt, ...) do { va_start(args, fmt); - len = vsnprintf(out->buf + out->pos, printbuf_remaining(out), fmt, args); + len = vsnprintf(out->buf + out->pos, printbuf_remaining_size(out), + fmt, args); va_end(args); - } while (len + 1 >= printbuf_remaining(out) && + } while (len >= printbuf_remaining_size(out) && !bch2_printbuf_make_room(out, len + 1)); len = min_t(size_t, len,