[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGWr4cSMme5B-bMc+maKccoYxgVeVKaXk7Eh=SOM7jX3Du5Rkw@mail.gmail.com>
Date: Wed, 1 Oct 2025 18:15:25 -0700
From: Octavian Purdila <tavip@...gle.com>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Cc: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, horms@...nel.org, ast@...nel.org, daniel@...earbox.net,
hawk@...nel.org, john.fastabend@...il.com, sdf@...ichev.me, kuniyu@...gle.com,
aleksander.lobakin@...el.com, toke@...hat.com, lorenzo@...nel.org,
netdev@...r.kernel.org, bpf@...r.kernel.org,
syzbot+ff145014d6b0ce64a173@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] xdp: update mem type when page pool is used for
generic XDP
On Wed, Oct 1, 2025 at 12:06 PM Maciej Fijalkowski
<maciej.fijalkowski@...el.com> wrote:
>
> On Wed, Oct 01, 2025 at 08:27:37AM -0700, Jakub Kicinski wrote:
> > On Wed, 1 Oct 2025 16:42:29 +0200 Maciej Fijalkowski wrote:
> > > Here we piggy back on sk_buff::pp_recycle setting as it implies underlying
> > > memory is backed by page pool.
> >
> > skb->pp_recycle means that if the pages of the skb came from a pp then
> > the skb is holding a pp reference not a full page reference on those
> > pages. It does not mean that all pages of an skb came from pp.
> > In practice it may be equivalent, especially here. But I'm slightly
> > worried that checking pp_recycle will lead to confusion..
>
> Mmm ok - maybe that's safer and straight-forward?
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 93a25d87b86b..7707a95ca8ed 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5269,6 +5269,9 @@ u32 bpf_prog_run_generic_xdp(struct sk_buff *skb, struct xdp_buff *xdp,
> orig_bcast = is_multicast_ether_addr_64bits(eth->h_dest);
> orig_eth_type = eth->h_proto;
>
> + xdp->rxq->mem.type = page_pool_page_is_pp(virt_to_page(xdp->data)) ?
> + MEM_TYPE_PAGE_POOL : MEM_TYPE_PAGE_SHARED;
> +
> act = bpf_prog_run_xdp(xdp_prog, xdp);
>
> /* check if bpf_xdp_adjust_head was used */
>
> As you know we do not have that kind of granularity within xdp_buff where
> we could distinguish the memory provider per linear part and each frag...
LGTM, based on my limited understanding. I can also confirm the syz
repro no longer crashes with this patch.
Powered by blists - more mailing lists