bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amery Hung <ameryhung@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
	alexei.starovoitov@gmail.com,  andrii@kernel.org,
	daniel@iogearbox.net, martin.lau@kernel.org,
	 mohsin.bashr@gmail.com, saeedm@nvidia.com, tariqt@nvidia.com,
	 mbloch@nvidia.com, maciej.fijalkowski@intel.com,
	kernel-team@meta.com
Subject: Re: [RFC bpf-next v1 3/7] bpf: Support pulling non-linear xdp data
Date: Tue, 26 Aug 2025 06:44:12 -0700	[thread overview]
Message-ID: <CAMB2axP59H5h5pLw4x-uu-CyJkds=BvzD6pa51PtAD2QRNhSfQ@mail.gmail.com> (raw)
In-Reply-To: <20250826062019.2140dd84@kernel.org>

On Tue, Aug 26, 2025 at 6:20 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> 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.

Got it. I will change to the new set of checks. The original kfunc
would return 0 when pointer wrapping happens and delta <= 0.

  reply	other threads:[~2025-08-26 13:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25 19:39 [RFC bpf-next v1 0/7] Add kfunc bpf_xdp_pull_data Amery Hung
2025-08-25 19:39 ` [RFC bpf-next v1 1/7] net/mlx5e: Fix generating skb from nonlinear xdp_buff Amery Hung
2025-08-27 13:45   ` Dragos Tatulea
2025-08-28  3:44     ` Amery Hung
2025-08-28 16:23       ` Dragos Tatulea
2025-08-28 13:41   ` Nimrod Oren
2025-08-25 19:39 ` [RFC bpf-next v1 2/7] bpf: Allow bpf_xdp_shrink_data to shrink a frag from head and tail Amery Hung
2025-08-28 13:43   ` Nimrod Oren
2025-08-25 19:39 ` [RFC bpf-next v1 3/7] bpf: Support pulling non-linear xdp data Amery Hung
2025-08-25 21:29   ` Stanislav Fomichev
2025-08-25 22:23     ` Amery Hung
2025-08-25 22:29       ` Jakub Kicinski
2025-08-25 22:36         ` Amery Hung
2025-08-25 22:46       ` Stanislav Fomichev
2025-08-25 22:58         ` Jakub Kicinski
2025-08-26  0:12           ` Stanislav Fomichev
2025-08-26  0:30             ` Jakub Kicinski
2025-08-25 22:39   ` Jakub Kicinski
2025-08-26  5:12     ` Amery Hung
2025-08-26 13:20       ` Jakub Kicinski
2025-08-26 13:44         ` Amery Hung [this message]
2025-08-25 19:39 ` [RFC bpf-next v1 4/7] bpf: Clear packet pointers after changing packet data in kfuncs Amery Hung
2025-08-25 19:39 ` [RFC bpf-next v1 5/7] bpf: Support specifying linear xdp packet data size in test_run Amery Hung
2025-08-25 19:39 ` [RFC bpf-next v1 6/7] selftests/bpf: Test bpf_xdp_pull_data Amery Hung
2025-08-25 19:39 ` [RFC bpf-next v1 7/7] selftests: drv-net: Pull data before parsing headers Amery Hung
2025-08-25 22:41 ` [RFC bpf-next v1 0/7] Add kfunc bpf_xdp_pull_data Jakub Kicinski
2025-08-26 19:38   ` Gal Pressman
2025-08-28 13:39 ` Nimrod Oren
2025-08-29  7:26   ` Amery Hung
2025-08-30  0:09     ` Jakub Kicinski
2025-08-29 18:21   ` Martin KaFai Lau

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='CAMB2axP59H5h5pLw4x-uu-CyJkds=BvzD6pa51PtAD2QRNhSfQ@mail.gmail.com' \
    --to=ameryhung@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@meta.com \
    --cc=kuba@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=martin.lau@kernel.org \
    --cc=mbloch@nvidia.com \
    --cc=mohsin.bashr@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).