Subject: Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6

From: Nicolas de Pesloüan<[email-masked]>
Date: Sun, 06 Mar 2011 14:08:33 +0100

Le 05/03/2011 23:09, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 10:30:33PM CET, [email-masked] wrote:
>> Hi,
>>
>> Comparing __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6,
>> I noticed an important difference: The ptype_base loop used to
>> deliver to orig_dev and this is not true anymore.
>
> I believe this is adressed by submitted patch " net: allow handlers to
> be processed for orig_dev"

I wonder whether we should address it that way (which is the former way to address it).

There are still a difference between ptype_all and ptype_base delivery:

- For ptype_all, we deliver to every device crossed while walking the rx_handler path (inside the 
another_round loop). (And there is no way to force exact match delivery).

- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest (skb->dev) and we 
can ask for exact match delivery.

This sounds very inconsistent. The only difference between ptype_all and ptype_base is the fact that 
ptype->type is NULL (wildcard) for the first and not NULL (a particular protocol) for the second.

I think we should:

1/ deliver to both ptype_all and ptype_base while walking the rx_handler path, but only exact match 
(ptype->dev == skb->dev).
2/ deliver to both ptype_all and ptype_base at the end of __netif_receive_skb(), but only wildcard 
match (ptype->dev == NULL), skipping this part if the last rx_handler returned RX_HANDLER_EXACT.

	Nicolas.

>> Imagine the following simple setup:
>>
>> eth0 ->  bond0
>>
>> - A packet handler registered on eth0, with ptype->type == NULL will
>> receive the packet, because it will be delivered in the ptype_all
>> loop, which is inside the another_round loop.
>> - The same packet handler, registered on eth0, but with ptype->type
>> != NULL won't receive the packet, because the ptype_base loop doesn't
>> deliver to orig_dev anymore.
>>
>> I think this can lead to a regression for user space: an application
>> using af_packet to listen to eth0 will receive the packet flow if the
>> registered protocol is NULL, but won't receive anything if the
>> registered protocol is not NULL.
>>
>> Can someone confirm?
>>
>> 	Nicolas.
>