From: Paolo Abeni <pabeni@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
horms@kernel.org, andrew+netdev@lunn.ch,
Willem de Bruijn <willemb@google.com>,
Katherine Leaver <kleaver@janestreet.com>,
Bjoern Doebel <doebel@amazon.de>,
stable@vger.kernel.org
Subject: Re: [PATCH net 2/2] packet: use ubuf_info completion for TX_RING packets
Date: Thu, 17 Sep 2026 11:16:19 +0200 [thread overview]
Message-ID: <a0b83186-7399-4d79-8226-ff43611184d7@redhat.com> (raw)
In-Reply-To: <20260914214229.1674102-3-willemdebruijn.kernel@gmail.com>
On 9/14/26 23:37, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> tpacket_snd sends skbs with frags pointing into its ring slots. Slots
> are released when skb->destructor is called.
>
> A call to skb_orphan calls skb->destructor before the skb is freed.
> This can cause the slot to be reused while still linked into the skb.
>
> Switch to standard zerocopy completion (ubuf_info) so the slot is only
> released once all references to the payload are freed or copied.
> Restore skb->destructor to standard sock_wfree.
>
> To prevent userspace from aliasing in-flight state on shared ring
> slots, allocate tpacket_uarg per packet, rather than per slot. This
> adds a small allocation to the transmit path. Use standard kmalloc to
> allow backporting to stable kernels.
>
> The uarg holds an sk_wmem_alloc reference, rather than an sk_refcnt
> reference. packet_free_tx_ring waits on sk_wmem_alloc before freeing
> the ring pages.
>
> As a result a slot is released when its payload is copied, which can
> be before transmission (e.g., in skb_orphan_frags_rx). Any slot
> timestamp then reflects the time of copy, rather than of transmit
> (or skb_orphan).
>
> Revert the now unused previous skb_zcopy_.._nouarg infra.
>
> Reported-by: Katherine Leaver <kleaver@janestreet.com>
> Reported-by: Bjoern Doebel <doebel@amazon.de>
> Closes: https://lore.kernel.org/netdev/20260909085542.3370986-1-doebel@amazon.de/
> Fixes: 5cd8d46ea156 ("packet: copy user buffers before orphan or clone")
> Cc: stable@vger.kernel.org
> Signed-off-by: Willem de Bruijn <willemb@google.com>
FTR both the 'high prio' sashiko finding here and the mid one on the
previous patch are IMHO worth addressing.
Also I'm wondering if the extra alloc/free is visible in perf figures?
Out of sheer ignorance, can't the ubuf be carved out of the ring?
/P
next prev parent reply other threads:[~2026-09-17 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 21:37 [PATCH net 0/2] packet: fix PACKET_TX_RING data corruption on skb_orphan Willem de Bruijn
2026-09-14 21:37 ` [PATCH net 1/2] virtio_net: copy zerocopy frags in start_xmit without NAPI Willem de Bruijn
2026-09-16 0:37 ` netdev-bot+sashiko
2026-09-14 21:37 ` [PATCH net 2/2] packet: use ubuf_info completion for TX_RING packets Willem de Bruijn
2026-09-16 0:37 ` netdev-bot+sashiko
2026-09-17 9:16 ` Paolo Abeni [this message]
2026-09-17 13:28 ` Willem de Bruijn
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=a0b83186-7399-4d79-8226-ff43611184d7@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=doebel@amazon.de \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kleaver@janestreet.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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