Messages in this thread | | | From | Andrii Nakryiko <> | Date | Mon, 3 May 2021 10:46:11 -0700 | Subject | Re: [PATCH v2 bpf-next] libbpf: Fix signed overflow in ringbuf_process_ring |
| |
On Mon, May 3, 2021 at 5:01 AM Brendan Jackman <jackmanb@google.com> wrote: > > On Fri, 30 Apr 2021 at 18:31, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > > > On Thu, Apr 29, 2021 at 6:05 AM Brendan Jackman <jackmanb@google.com> wrote: > > > > 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; > > Sure, it has all the same implicit casts/promotions but I guess it's > clearer anyway.
I might be wrong, but given INT_MAX is defined as
# define INT_MAX 2147483647
(notice no suffix specifying which type it is), this constant will be interpreted by compiler as desired type in the given context. So in
if (cnt > INT_MAX)
INT_MAX should be a uint64_t constant. But even if not, it is up-converted to int64_t with no loss anyway.
> > > If you don't mind, I can patch it up while applying? > > Yes please do, thanks!
So while doing that I noticed that you didn't fix ring_buffer__poll(), so I had to fix it up a bit more extensively. Please check the end result in bpf tree and let me know if there are any problems with it:
2a30f9440640 ("libbpf: Fix signed overflow in ringbuf_process_ring")
| |