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:	Thu, 15 Feb 2007 15:45:23 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Andy Gospodarek <andy@...yhouse.net>
cc:	David Miller <davem@...emloft.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 

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

[...]
>That might be the case, but I feel like the code is in a place where it
>*could* work tomorrow with just some small tweaks (getting everything
>into process context).  I'm reluctant to cram a whole bunch of changes
>down someone's throat immediately (with a big patch) because it will be
>difficult to learn incrementally what is being done well and what isn't
>based on user feedback.

	Fair enough.

>> 	I like having the mode-specific monitors simply be special case
>> monitors in a unified "monitor system." It resolves the link-check
>> vs. mode-specific conflict, and allows all of the periodic things to be
>> paused as a set for mutexing purposes.  I'm happy to be convinced that
>> I'm just blowing hooey here, but that's how it seems to me.
>> 
>
>I went back and looked at my patch from a few months ago and I actually
>use a single-threaded workqueue for each bond device.  I did not use
>different queues to replace each timer -- just different types of work
>that is placed on the queue.  So it sounds like we agree -- now we just
>need to pick a decent starting point?

	For the short term, yes, I don't have any disagreement with
switching the timer based stuff over to workqueues.  Basically a one for
one replacement to get the functions in a process context and tweak the
locking.

	I do think we're having a little confusion over details of
terminology; if I'm not mistaken, you're thinking that workqueue means
single threaded: even though each individual "monitor thingie" is a
separate piece of work, they still can't collide.

	That's true, but (unless I've missed a call somewhere) there
isn't a "wq_pause_for_a_bit" type of call (that, e.g., waits for
anything running to stop, then doesn't run any further work until we
later tell it to), so suspending all of the periodic things running for
the bond is more hassle than if there's just one schedulable work thing,
which internally calls the right functions to do the various things.
This is also single threaded, but easier to stop and start.  It seems to
be simpler to have multiple link monitors running in such a system as
well (without having them thrashing the link state as would happen now).

	-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