Re: [PATCH net v4 3/3] net: skbuff: don't touch shared zerocopy state in skb_tx_error()
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2026-08-23 18:26:53
Also in:
lkml
Norbert Szetei wrote:
skb_tx_error() completes the zerocopy uarg and clears
SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears
SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone
shares, while the caller only owns the reference it is about to drop.
Through a clone it tells the producer its pages are free and drops
SKBFL_SHARED_FRAG for an skb that is still in flight.
Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC:
clone_execute() sends a skb_clone() into ovs_dp_process_packet() while
do_execute_actions() keeps forwarding the original, and skb_clone()
does not privatise the frags here -- skb_orphan_frags() returns early
on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker
from the packet still being forwarded, and a later local ESP delivery
decrypts in place over frags it does not own privately.
Skip it for a cloned skb. Nothing is lost: skb_release_data() clears
the zerocopy state once the last reference to the shared data goes.
Fixes: 25121173f7b1 ("skb: api to report errors for zero copy skbs")
Cc: stable@vger.kernel.org
Suggested-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Norbert Szetei <redacted>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Tested-by: Jongmin Jang <redacted>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Took me some time to wrap my head around this one, because
There are two independent types of zerocopy in this context:
1. skb_zerocopy(), used by nfqueue and ovs to create a derived skb
2. skb_zcopy(), skbs with "zerocopy" page frags
And there second has two variants:
2A. original, such as vhost-net, that do not support refcounting and
thus must be downgraded on skb_clone() and such
2B. SKBFL_DONT_ORPHAN, that support clones through refcounting
The bug here is modifying shared shinfo fields of cloned skbs, so
affects type 2B skbs only.
skb_tx_error was introduced for type 2A skbs, predates refcounting.
For type 2B, the signal is indeed generated at skb_release_data.
So LGTM.
quoted hunk ↗ jump to hunk
--- net/core/skbuff.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)diff --git a/net/core/skbuff.c b/net/core/skbuff.c index ab3d161247b9..b9541329f1a7 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c@@ -1417,10 +1417,13 @@ EXPORT_SYMBOL(skb_dump); * * Report xmit error if a device callback is tracking this skb. * skb must be freed afterwards. + * + * Does nothing for a cloned skb: the zerocopy state lives in + * skb_shinfo(), which the clones share. */ void skb_tx_error(struct sk_buff *skb) { - if (skb) { + if (skb && !skb_cloned(skb)) { skb_zcopy_downgrade_managed(skb); skb_zcopy_clear(skb, true); }-- 2.55.0