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
| ||
|
Date: Sun, 06 Mar 2011 14:08:33 +0100 From: Nicolas de Pesloüan <nicolas.2p.debian@...il.com> To: Jiri Pirko <jpirko@...hat.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 Le 05/03/2011 23:09, Jiri Pirko a écrit : > 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" 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. > -- 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