All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fedor Tokarev <ftokarev@gmail.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Jiri Olsa <olsajiri@gmail.com>,
	Fedor Tokarev <ftokarev@gmail.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	bpf <bpf@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bpf: btf: Fix vsnprintf return value check
Date: Fri, 15 Jul 2022 09:07:42 +0200	[thread overview]
Message-ID: <20220715070742.GA165641@laptop> (raw)
In-Reply-To: <ef44abe0-81fc-9c97-a4e4-2b3ba19cd84f@oracle.com>

On Thu, Jul 14, 2022 at 11:06:22AM +0100, Alan Maguire wrote:
> On 13/07/2022 19:40, Andrii Nakryiko wrote:
> > On Mon, Jul 11, 2022 at 2:45 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >>
> >> On Mon, Jul 11, 2022 at 11:13:17PM +0200, Fedor Tokarev wrote:
> >>> vsnprintf returns the number of characters which would have been written if
> >>> enough space had been available, excluding the terminating null byte. Thus,
> >>> the return value of 'len_left' means that the last character has been
> >>> dropped.
> >>
> >> should we have test for this in progs/test_snprintf.c ?
> > 
> > It might be too annoying to set up such test, and given the fix is
> > pretty trivial IMO it's ok without extra test. But cc Alan for ack.
> > Alan, please take a look as well.
> > 
> 
> I can follow up with a test, it should be okay I think (we can use
> the "don't show types" flag and tryp to print "10" with a 2-byte len or
> similar).

I'll gladly give it a try.

> In terms of the fix, it looks good, but given that the code is tricky, 
> it might be good to expand a bit on the explanation. Something like the below?
> 
Agreed.

> "When using btf_type_snprintf_show(), the user passes in a "len" value, and
> we use it to initialize ssnprintf.len_left, indicating how much space
> remains for the string representation, including the null byte, so "len - 1" 
> bytes are actually available for the actual string data, leaving one for 
> the terminating null byte.
> 
> In btf_snprintf_show() - which is passed the ssnprintf data as an argument -
> vsnprintf() returns the len that would have been written, and this _excludes_ 
> the null terminator. But we want to handle cases where the length of the string
> to be written (excluding the null terminator) exactly matches the original len 
> value we passed in (len == len_left) in the same way was we do other
> overflow cases (len > len_left)."
> 
> Acked-by: Alan Maguire <alan.maguire@oracle.com>
> 
> >>
> >> jirka
> >>
> >>>
> >>> Signed-off-by: Fedor Tokarev <ftokarev@gmail.com>
> >>> ---
> >>>  kernel/bpf/btf.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> >>> index eb12d4f705cc..a9c1c98017d4 100644
> >>> --- a/kernel/bpf/btf.c
> >>> +++ b/kernel/bpf/btf.c
> >>> @@ -6519,7 +6519,7 @@ static void btf_snprintf_show(struct btf_show *show, const char *fmt,
> >>>       if (len < 0) {
> >>>               ssnprintf->len_left = 0;
> >>>               ssnprintf->len = len;
> >>> -     } else if (len > ssnprintf->len_left) {
> >>> +     } else if (len >= ssnprintf->len_left) {
> >>>               /* no space, drive on to get length we would have written */
> >>>               ssnprintf->len_left = 0;
> >>>               ssnprintf->len += len;
> >>> --
> >>> 2.25.1
> >>>

  reply	other threads:[~2022-07-15  7:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 21:13 [PATCH] bpf: btf: Fix vsnprintf return value check Fedor Tokarev
2022-07-11 21:42 ` Jiri Olsa
2022-07-13 18:40   ` Andrii Nakryiko
2022-07-14 10:06     ` Alan Maguire
2022-07-15  7:07       ` Fedor Tokarev [this message]
2022-07-25  7:41         ` Alan Maguire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220715070742.GA165641@laptop \
    --to=ftokarev@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=olsajiri@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.