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
| ||
|
Message-ID: <31653.1391725983@death.nxdomain> Date: Thu, 06 Feb 2014 14:33:03 -0800 From: Jay Vosburgh <fubar@...ibm.com> To: Cong Wang <cwang@...pensource.com> cc: Thomas Glanzmann <thomas@...nzmann.de>, Eric Dumazet <eric.dumazet@...il.com>, netdev <netdev@...r.kernel.org>, Veaceslav Falico <vfalico@...hat.com>, andy@...yhouse.net, Jiří Pírko <jiri@...nulli.us>, "sfeldma@...ulusnetworks.com" <sfeldma@...ulusnetworks.com> Subject: Re: RTNL: assertion failed at net/core/dev.c (4494) and RTNL: assertion failed at net/core/rtnetlink.c (940) Cong Wang <cwang@...pensource.com> wrote: >On Thu, Feb 6, 2014 at 2:07 PM, Jay Vosburgh <fubar@...ibm.com> wrote: >> Jay Vosburgh <fubar@...ibm.com> wrote: >> >>>Cong Wang <cwang@...pensource.com> wrote: >>> >>> >>> That would eliminate the warning, but is suboptimal. Acquiring >>>RTNL is not necessary on the vast majority of state machine runs >>>(because no state changes take place, i.e., no ports are disabled or >>>enabled). The above change would add 10 round trips per second to RTNL, >>>which seems excessive. >>> >>> Also, we cannot unconditionally acquire RTNL in this function, >>>as it would race with the call to cancel_delayed_work_sync from >>>bond_close (via bond_work_cancel_all). > >OK. > >> >> Thought of one more problem: we can't hold a regular lock while >> calling rtmsg_ifinfo, as it may sleep in alloc_skb. The rtmsg_ifinfo >> call has to be RTNL and nothing else. >> > >s/GFP_KERNEL/GFP_ATOMIC/ Yah, that would help with extra locks, but not totally solve things. I'm looking around, and seeing a number of other places that will end up at one of these rtmsg_ifinfo calls with incorrect locking: bond_ab_arp_probe calls via bond_set_slave_active_flags and bond_set_slave_inactive_flags without RTNL. bond_change_active_slave calls via bond_set_slave_inactive_flags and bond_set_slave_active_flags with other locks held, and maybe without RTNL; I'm not sure if bond_option_active_slave_set holds RTNL when it calls bond_select_active_slave. bond_open calls via bond_set_slave_active_flags and bond_set_slave_inactive_flags with RTNL, but also with other locks held. bond_loadbalance_arp_mon calls bond_set_active_slave and bond_set_backup_slave without RTNL. This is in addition to the cases in the 802.3ad code from __enable_port and __disable_port calls. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.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