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]

Date:	Tue, 13 Feb 2007 14:26:28 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Andy Gospodarek <andy@...yhouse.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, netdev@...r.kernel.org,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	lpiccilli@...re.com.br,
	"bugme-daemon@...nel-bugs.osdl.org" 
	<bugme-daemon@...zilla.kernel.org>
Subject: Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0 

Andy Gospodarek <andy@...yhouse.net> wrote:

[...]
>I've been working off and on for a little while to resolve these issues
>and even posted a patch not long ago to address some these by removing
>the timers and using workqueues instead.  This enabled resolution of
>quite a few of the issues with bonding since the code was no longer
>running in an atomic context and could now more easily take locks.
[...]
>On the side I've also been working to keep the timers and take the rtnl
>lock in the correct place so avoid messages like these:

	I've also been giving this some thought.

	I'm all in favor of moving the timers to work queues, and
eventually dispatching all of the various things from a single common
handler.  The advantage of concentrating everything like that it
effectively mutexes all of the timer things against one another, and
disabling (pausing) the work queue then provides mutexing against any of
the things that are dispated by timed events.  That single thread can
acquire rtnl when it needs to, which mutexes against the user initiated
events (add or remove slave, change active, etc) since those also hold
rtnl.  Some of that is further down the road, but I've prototyped it
out.

	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.

	Moving the slave lists to read copy doesn't help with this
particular problem, as it's necessary to read copy unlock before going
into something that might sleep (which is the big problem, when the alb
code calls dev_set_mac_address()).  Unless I'm misremembering how RCU
hangs together.

	-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