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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Mar 2011 22:05:11 +0100
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Changli Gao <xiaosuo@...il.com>
CC:	Jiri Pirko <jpirko@...hat.com>, netdev@...r.kernel.org,
	davem@...emloft.net, fubar@...ibm.com, eric.dumazet@...il.com,
	andy@...yhouse.net, Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame

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@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html