Herbert Xu wrote:
> I think I understand your patch now.  What's happening is that
> 
> 1) The skb is sent to socket 1.
> 2) Someone does a recvmsg on socket 1 and drops the ref on the skb.
>    Note that the rmalloc is not returned at this point since the
>    skb is still referenced.
> 3) The same skb is now sent to socket 2.

Ahh, even I get the point now.
I actually thought this was caused by another race. More on that later.

> I agree with your solution except that we should still do the skb_get
> if we can.  Here is my version where we only do the skb_get at the
> start.

What about an alternative fix, that avoids even more cloning (where
possible)? This resurrects the skb_orphan call that was moved out, last
time we had 'shared-skb troubles'. It is practically a no-op in the
common case, but still prevents the possible race with recvmsg.
(And I have a weakness for one-line-fixes). :-)


Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>