Re: [PATCH net v4 3/3] net: skbuff: don't touch shared zerocopy state in skb_tx_error()

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

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 <norbert@doyensec.com>
> Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
> Tested-by: Jongmin Jang <payload.jang@gmail.com>

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.

> ---
>  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
>