netdev - Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070213.143243.78711492.davem@davemloft.net>
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