| 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: Tue, 13 Feb 2007 14:32:43 -0800 (PST) From: David Miller <davem@...emloft.net> To: fubar@...ibm.com Cc: andy@...yhouse.net, akpm@...ux-foundation.org, netdev@...r.kernel.org, shemminger@...ux-foundation.org, lpiccilli@...re.com.br, bugme-daemon@...zilla.kernel.org Subject: Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0 From: Jay Vosburgh <fubar@...ibm.com> Date: Tue, 13 Feb 2007 14:26:28 -0800 > In reference to Andy's recent patch (which first did conditional > locking for rtnl, then later acquired rtnl for every entry into the > timer function), I know the conditional locking isn't popular, but it > seems to me that it's a less bad alternative than holding rtnl every > time the bond_mii_monitor() runs (typically 10 - 50 times per second). > Or is the rtnl lock really so cheap that this isn't an issue? The > overwhelming majority of cases the mii_monitor won't need to do anything > that requires rtnl, so only holding it when needed is better. We definitely don't want to take the RTNL that often if it can be avoided. Maybe if you put the RTNL acquisition deeper into the call path, ie. down into the code that knows RTNL is needed, perhaps it won't be so ugly. Replace the conditions with functions. - 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