[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250826062019.2140dd84@kernel.org>
Date: Tue, 26 Aug 2025 06:20:19 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Amery Hung <ameryhung@...il.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org,
alexei.starovoitov@...il.com, andrii@...nel.org, daniel@...earbox.net,
martin.lau@...nel.org, mohsin.bashr@...il.com, saeedm@...dia.com,
tariqt@...dia.com, mbloch@...dia.com, maciej.fijalkowski@...el.com,
kernel-team@...a.com
Subject: Re: [RFC bpf-next v1 3/7] bpf: Support pulling non-linear xdp data
On Mon, 25 Aug 2025 22:12:21 -0700 Amery Hung wrote:
> > > + data_end = xdp->data + len;
> > > + delta = data_end - xdp->data_end;
> > > +
> > > + if (delta <= 0)
> > > + return 0;
> > > +
> > > + if (unlikely(data_end > data_hard_end))
> > > + return -EINVAL;
> >
> > Is this safe against pointers wrapping on 32b systems?
> >
>
> You are right. This may be a problem.
>
> > Maybe it's better to do:
> >
> > if (unlikely(data_hard_end - xdp->data_end < delta))
> >
> > ?
>
> But delta may be negative if the pointer wraps around and then the
> function will still continue. How about adding data_end < xdp->data
> check and reorganizing the checks like this?
You already checked that delta is positive in the previous if (),
so I think it's safe. Admittedly having 3 separate conditions is
more readable but it's not strictly necessary. Up to you.
Powered by blists - more mailing lists