Netdev List
 help / color / mirror / Atom feed
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


  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