[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171228.143003.2150809989896051605.davem@davemloft.net>
Date: Thu, 28 Dec 2017 14:30:03 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: willemdebruijn.kernel@...il.com
Cc: netdev@...r.kernel.org, willemb@...gle.com
Subject: Re: [PATCH net] skbuff: in skb_copy_ubufs unclone before releasing
zerocopy
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Date: Thu, 28 Dec 2017 12:38:13 -0500
> From: Willem de Bruijn <willemb@...gle.com>
>
> skb_copy_ubufs must unclone before it is safe to modify its
> skb_shared_info with skb_zcopy_clear.
>
> Commit b90ddd568792 ("skbuff: skb_copy_ubufs must release uarg even
> without user frags") ensures that all skbs release their zerocopy
> state, even those without frags.
>
> But I forgot an edge case where such an skb arrives that is cloned.
>
> The stack does not build such packets. Vhost/tun skbs have their
> frags orphaned before cloning. TCP skbs only attach zerocopy state
> when a frag is added.
>
> But if TCP packets can be trimmed or linearized, this might occur.
> Tracing the code I found no instance so far (e.g., skb_linearize
> ends up calling skb_zcopy_clear if !skb->data_len).
>
> Still, it is non-obvious that no path exists. And it is fragile to
> rely on this.
>
> Fixes: b90ddd568792 ("skbuff: skb_copy_ubufs must release uarg even without user frags")
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
Applied and queued up for -stable.
Powered by blists - more mailing lists