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: Mon, 10 Oct 2011 09:27:24 -0700 From: Ben Greear <greearb@...delatech.com> To: Eric Dumazet <eric.dumazet@...il.com> CC: netdev <netdev@...r.kernel.org> Subject: Re: [PATCH net-next] macvlan: handle fragmented multicast frames On 10/06/2011 01:28 PM, Eric Dumazet wrote: > Le mercredi 05 octobre 2011 à 15:35 -0700, Ben Greear a écrit : > >> If someone wants to cook up macvlan-ip-defrag patch I'll be happy >> to test it. But, as far as I can tell, this problem can happen on >> any two interfaces. The reason that some of mine work (.1q vlans) >> and macvlan didn't is probably because those were separated by >> some virtual network links that imparted extra delay...so the >> vlan consumed all its fragments and passed the complete pkt up >> the stack before the mac-vlan ever saw the initial frame. >> >> With this in mind, it seems that using multiple udp multicast >> sockets bound to specific devices is fundamentally broken for >> fragmented packets. >> >> I have no pressing need for this feature, so now that I better understand >> the problem I can just document it and move on to other things. >> >> Thanks for all the help. >> > > Please test following patch (note I had no time to test it, sorry !) > > Based on net-next tree, might apply on 3.0 kernel... > > [PATCH net-next] macvlan: handle fragmented multicast frames > > Fragmented multicast frames are delivered to a single macvlan port, > because ip defrag logic considers other samples are redundant. > > Implement a defrag step before trying to send the multicast frame. I applied this to Linus' top-of-tree this morning and it does appear to fix the problem for mac-vlans. I do see this error, but I doubt it has anything to do with your patch: device eth0 entered promiscuous mode device rddVR10 entered promiscuous mode ADDRCONF(NETDEV_CHANGE): rddVR1b: link becomes ready ================================================ [ BUG: lock held when returning to user space! ] ------------------------------------------------ ip/3452 is leaving the kernel with locks still held! 1 lock held by ip/3452: #0: (rcu_read_lock){.+.+..}, at: [<f8c5336f>] rcu_read_lock+0x0/0x26 [ipv6] ADDRCONF(NETDEV_CHANGE): rddVR4b: link becomes ready ADDRCONF(NETDEV_CHANGE): rddVR5b: link becomes ready I have no idea why it doesn't print out a more useful stack trace. It seems repeatable (2 of 2 reboots so far). I'm configuring a pretty complex virtual network, with veth devices, xorp instances running ipv4 and ipv6 routing protocols, etc. This is a clean upstream kernel with no outside patches aside from your own. Thanks, Ben -- Ben Greear <greearb@...delatech.com> Candela Technologies Inc http://www.candelatech.com -- 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