All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Brendan Jackman <jackmanb@google.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	KP Singh <kpsingh@kernel.org>,
	Florent Revest <revest@chromium.org>
Subject: Re: [PATCH v2 bpf-next] libbpf: Fix signed overflow in ringbuf_process_ring
Date: Fri, 30 Apr 2021 09:31:36 -0700	[thread overview]
Message-ID: <CAEf4BzY7sx0gW=o5rM8WDzW1J0U_Yep3MMuJScoMg-hBAeBPCg@mail.gmail.com> (raw)
In-Reply-To: <20210429130510.1621665-1-jackmanb@google.com>

On Thu, Apr 29, 2021 at 6:05 AM Brendan Jackman <jackmanb@google.com> wrote:
>
> One of our benchmarks running in (Google-internal) CI pushes data
> through the ringbuf faster htan than userspace is able to consume
> it. In this case it seems we're actually able to get >INT_MAX entries
> in a single ringbuf_buffer__consume call. ASAN detected that cnt
> overflows in this case.
>
> Fix by using 64-bit counter internally and then capping the result to
> INT_MAX before converting to the int return type.
>
> Fixes: bf99c936f947 (libbpf: Add BPF ring buffer support)
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
>
> diff v1->v2: Now we don't break the loop at INT_MAX, we just cap the reported
> entry count.
>
> Note: I feel a bit guilty about the fact that this makes the reader
> think about implicit conversions. Nobody likes thinking about that.
>
> But explicit casts don't really help with clarity:
>
>   return (int)min(cnt, (int64_t)INT_MAX); // ugh
>

I'd go with

if (cnt > INT_MAX)
    return INT_MAX;

return cnt;

If you don't mind, I can patch it up while applying?

> shrug..
>
>  tools/lib/bpf/ringbuf.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/tools/lib/bpf/ringbuf.c b/tools/lib/bpf/ringbuf.c
> index e7a8d847161f..2e114c2d0047 100644
> --- a/tools/lib/bpf/ringbuf.c
> +++ b/tools/lib/bpf/ringbuf.c
> @@ -204,7 +204,9 @@ static inline int roundup_len(__u32 len)
>
>  static int ringbuf_process_ring(struct ring* r)
>  {
> -       int *len_ptr, len, err, cnt = 0;
> +       int *len_ptr, len, err;
> +       /* 64-bit to avoid overflow in case of extreme application behavior */
> +       int64_t cnt = 0;
>         unsigned long cons_pos, prod_pos;
>         bool got_new_data;
>         void *sample;
> @@ -240,7 +242,7 @@ static int ringbuf_process_ring(struct ring* r)
>                 }
>         } while (got_new_data);
>  done:
> -       return cnt;
> +       return min(cnt, INT_MAX);
>  }
>
>  /* Consume available ring buffer(s) data without event polling.
> @@ -263,8 +265,8 @@ int ring_buffer__consume(struct ring_buffer *rb)
>  }
>
>  /* Poll for available data and consume records, if any are available.
> - * Returns number of records consumed, or negative number, if any of the
> - * registered callbacks returned error.
> + * Returns number of records consumed (or INT_MAX, whichever is less), or
> + * negative number, if any of the registered callbacks returned error.
>   */
>  int ring_buffer__poll(struct ring_buffer *rb, int timeout_ms)
>  {
> --
> 2.31.1.498.g6c1eba8ee3d-goog
>

  reply	other threads:[~2021-04-30 16:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29 13:05 [PATCH v2 bpf-next] libbpf: Fix signed overflow in ringbuf_process_ring Brendan Jackman
2021-04-30 16:31 ` Andrii Nakryiko [this message]
2021-05-03 12:01   ` Brendan Jackman
2021-05-03 17:46     ` Andrii Nakryiko
2021-05-04  9:01       ` Brendan Jackman
2021-05-05  0:37         ` Andrii Nakryiko

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='CAEf4BzY7sx0gW=o5rM8WDzW1J0U_Yep3MMuJScoMg-hBAeBPCg@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jackmanb@google.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=revest@chromium.org \
    /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.