Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame

["Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>]

Le 02/03/2011 17:13, Changli Gao a écrit :
> On Wed, Mar 2, 2011 at 4:11 AM, Nicolas de Pesloüan
> <nicolas.2p.debian@gmail.com>  wrote:
>> Le 01/03/2011 16:12, Changli Gao a écrit :
>>> I don't think so. Although you avoid netif_rx(), you can't avoid
>>> ptype_all handlers. In fact, all the RX handlers should has this
>>> check(), if they may modify the skb.
>>
>> Can you please develop your explanation?
>>
>> In current __netif_receive_skb() (after the recent patch from Jiri), we
>> deliver the skb to ptype_all handlers inside a loop, while possibly changing
>> skb->dev inside this loop.
>>
>> Then, at the end of __netif_receive_skb(), we loop on ptype_base, without
>> changing anything in skb.
>>
>> Should we consider ptype_*->func() to be called in a pure sequential way?
>> Should we consider that when a ptype_*->func() returns, nothing from this
>> handler will use the skb in anyway later, in a parallel way?
>>
>> Or should we, instead, consider that special precautions must be taken,
>> because protocol handlers may run in parallel for the same skb? Which kind
>> of precautions?
>>
>
> If the packets gotten by __netif_receive_skb() are unshared, the skb
> gotten by bond should be unshared, as we call prev_pt before calling
> bond. I don't see there is any  relationship with the previous patch
> from Jiri. The bridge is in the same condition with bond here, and it
> checks if the skb is shared or not. Does it imply that dev->rx_handler
> may see shared skbs?

Thanks for you explanations.

My question is not strictly linked to bonding, but more general to __netif_receive_skb().

Jiri's patch added a "goto another_round" if the rx_handler changed skb->dev. (The idea was from 
me). The ptype_all list_foreach_entry_rcu delivery loop is between "another_round:" and "goto 
another_round", so some ptype_all handlers will receive an skb where skb->dev will have changed.

I wonder whether this might cause any troubles and if yes, what should be done to fix it.

And depending on the answer, I wonder whether we can move the ptype_base loop to the same place as 
the ptype_all loop. This would allow for a better handling of orig_dev, I think.

	Nicolas.