[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110305220938.GK8573@psychotron.redhat.com>
Date: Sat, 5 Mar 2011 23:09:39 +0100
From: Jiri Pirko <jpirko@...hat.com>
To: Nicolas de Pesloüan
<nicolas.2p.debian@...il.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Stephen Hemminger <shemminger@...tta.com>,
Jay Vosburgh <fubar@...ibm.com>,
Patrick Mc Hardy <kaber@...sh.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Andy Gospodarek <andy@...yhouse.net>
Subject: Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7
and net-next-2.6
Sat, Mar 05, 2011 at 10:30:33PM CET, nicolas.2p.debian@...il.com 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"
>
>[Note that this is unrelated to Jiri's today's patch that remove the
>orig_dev parameter to protocol handler].
>
>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.
--
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
Powered by blists - more mailing lists