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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 02 May 2007 07:40:31 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: Patrick McHardy <kaber@...sh.net> Cc: hadi@...erus.ca, Pavel Emelianov <xemul@...ru>, David Miller <davem@...emloft.net>, Ben Greear <greearb@...delatech.com>, Linux Netdev List <netdev@...r.kernel.org>, Linux Containers <containers@...ts.osdl.org>, Kirill Korotaev <dev@...ru>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, devel@...nvz.org, Stephen Hemminger <shemminger@...ux-foundation.org> Subject: Re: [PATCH] Virtual ethernet device (tunnel) Patrick McHardy <kaber@...sh.net> writes: > jamal wrote: >> On Wed, 2007-02-05 at 14:34 +0200, Patrick McHardy wrote: >> >> >>>Thats a lot better than using sysfs, but I think it would be >>>preferrable to use rtnetlink instead of genetlink for network >>>configuration. >> >> >> or you can just hold rtnl while using genl. >> I do agree it would be easier to just use rtnetlink ... > > > The rtnl needs to be held in either case, but using a different > netlink family introduces races in message processing. For example > a simple: > > ip link add dev veth0 > ip route add 10.0.0.0/8 dev veth0 > > might fail because we have two different input queues and the routing > message might get processed before the link message. The consensus from the last thread was pretty much that we need to implement RTM_NEWLINK and RTM_DELLINK, if it is at all possible. So that we can get code reuse between different virtual devices. Although I suspect we will need some per type attribute parsing. Eric - 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