From: Jakub Kicinski <kuba@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: Octavian Purdila <tavip@google.com>, <davem@davemloft.net>,
<edumazet@google.com>, <pabeni@redhat.com>, <horms@kernel.org>,
<ast@kernel.org>, <daniel@iogearbox.net>, <hawk@kernel.org>,
<john.fastabend@gmail.com>, <sdf@fomichev.me>,
<ahmed.zaki@intel.com>, <aleksander.lobakin@intel.com>,
<toke@redhat.com>, <lorenzo@kernel.org>, <netdev@vger.kernel.org>,
<bpf@vger.kernel.org>,
<syzbot+ff145014d6b0ce64a173@syzkaller.appspotmail.com>,
Kuniyuki Iwashima <kuniyu@google.com>
Subject: Re: [PATCH net] xdp: use multi-buff only if receive queue supports page pool
Date: Fri, 26 Sep 2025 12:40:10 -0700 [thread overview]
Message-ID: <20250926124010.4566617b@kernel.org> (raw)
In-Reply-To: <aNZ33HRt+SxltbcP@boxer>
On Fri, 26 Sep 2025 13:24:12 +0200 Maciej Fijalkowski wrote:
> On Fri, Sep 26, 2025 at 12:33:46AM -0700, Octavian Purdila wrote:
> > On Thu, Sep 25, 2025 at 7:12 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > Ah, yes, you are right. So my comment in the commit message about
> > TUN/TAP registering a page shared memory model is wrong. But I think
> > the fix is still correct for the reported syzkaller issue. From
> > bpf_prog_run_generic_xdp:
> >
> > rxqueue = netif_get_rxqueue(skb);
> > xdp_init_buff(xdp, frame_sz, rxq: &rxqueue->xdp_rxq);
> >
> > So xdp_buff's rxq is set to the netstack queue for the generic XDP
> > hook. And adding the check in netif_skb_check_for_xdp based on the
> > netstack queue should be correct, right?
>
> Per my limited understanding your change is making skb_cow_data_for_xdp()
> a dead code as I don't see mem model being registered for these stack
> queues - netif_alloc_rx_queues() only calls xdp_rxq_info_reg() and
> mem.type defaults to MEM_TYPE_PAGE_SHARED as it's defined as 0, which
> means it's never going to be MEM_TYPE_PAGE_POOL.
Hah, that's a great catch, how did I miss that..
The reason for the cow is that frags can be shared, we are not allowed
to modify them. It's orthogonal.
> IMHO that single case where we rewrite skb to memory backed by page pool
> should have it reflected in mem.type so __xdp_return() potentially used in
> bpf helpers could act correctly.
>
> > > Well, IDK how helpful the flow below would be but:
> > >
> > > veth_xdp_xmit() -> [ptr ring] -> veth_xdp_rcv() -> veth_xdp_rcv_one()
> > > |
> > > | xdp_convert_frame_to_buff() <-'
> > > ( "re-stamps" ;) -> | xdp->rxq = &rq->xdp_rxq;
> > > can eat frags but now rxq | bpf_prog_run_xdp()
> > > is veth's |
> > >
> > > I just glanced at the code so >50% changes I'm wrong, but that's what
> > > I meant.
> >
> > Thanks for the clarification, I thought that "re-stamps" means the:
> >
> > xdp->rxq->mem.type = frame->mem_type;
> >
> > from veth_xdp_rcv_one in the XDP_TX/XDP_REDIRECT cases.
> >
> > And yes, now I think the same issue can happen because veth sets the
> > memory model to MEM_TYPE_PAGE_SHARED but veth_convert_skb_to_xdp_buff
> > calls skb_pp_cow_data that uses page_pool for allocations. I'll try to
> > see if I can adapt the syzkaller repro to trigger it for confirmation.
>
> That is a good catch.
FWIW I think all calls to xdp_convert_frame_to_buff() must come with
the hack that cpu_map_bpf_prog_run_xdp() is doing today. Declare rxq
on the stack and fill in the mem info there. I wonder if we should add
something to the API (xdp_convert_frame_to_buff()) to make sure people
don't forget to do this..
next prev parent reply other threads:[~2025-09-26 19:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 6:08 [PATCH net] xdp: use multi-buff only if receive queue supports page pool Octavian Purdila
2025-09-25 0:09 ` Jakub Kicinski
2025-09-25 7:53 ` Octavian Purdila
2025-09-25 9:42 ` Maciej Fijalkowski
2025-09-26 2:12 ` Jakub Kicinski
2025-09-26 7:33 ` Octavian Purdila
2025-09-26 11:24 ` Maciej Fijalkowski
2025-09-26 19:40 ` Jakub Kicinski [this message]
2025-09-30 0:01 ` Octavian Purdila
2025-09-30 17:41 ` Jakub Kicinski
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=20250926124010.4566617b@kernel.org \
--to=kuba@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuniyu@google.com \
--cc=lorenzo@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=syzbot+ff145014d6b0ce64a173@syzkaller.appspotmail.com \
--cc=tavip@google.com \
--cc=toke@redhat.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 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.