From: Jakub Kicinski <kuba@kernel.org>
To: Octavian Purdila <tavip@google.com>
Cc: 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,
uniyu@google.com, 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
Subject: Re: [PATCH net] xdp: use multi-buff only if receive queue supports page pool
Date: Wed, 24 Sep 2025 17:09:14 -0700 [thread overview]
Message-ID: <20250924170914.20aac680@kernel.org> (raw)
In-Reply-To: <20250924060843.2280499-1-tavip@google.com>
On Wed, 24 Sep 2025 06:08:42 +0000 Octavian Purdila wrote:
> When a BPF program that supports BPF_F_XDP_HAS_FRAGS is issuing
> bpf_xdp_adjust_tail and a large packet is injected via /dev/net/tun a
> crash occurs due to detecting a bad page state (page_pool leak).
>
> This is because xdp_buff does not record the type of memory and
> instead relies on the netdev receive queue xdp info. Since the TUN/TAP
> driver is using a MEM_TYPE_PAGE_SHARED memory model buffer, shrinking
> will eventually call page_frag_free. But with current multi-buff
> support for BPF_F_XDP_HAS_FRAGS programs buffers are allocated via the
> page pool.
>
> To fix this issue check that the receive queue memory mode is of
> MEM_TYPE_PAGE_POOL before using multi-buffs.
This can also happen on veth, right? And veth re-stamps the Rx queues.
next prev parent reply other threads:[~2025-09-25 0:09 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 [this message]
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
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=20250924170914.20aac680@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=lorenzo@kernel.org \
--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 \
--cc=uniyu@google.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.