linux-kernel - Re: [PATCH 1/9] workqueue: perform cpu down operations from low priority cpu

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:	Sat, 21 Jul 2012 14:36:56 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	peterz@...radead.org, tglx@...utronix.de, linux-pm@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/9] workqueue: perform cpu down operations from low
 priority cpu_notifier()

On Fri, Jul 20, 2012 at 02:58:35PM -0700, Tejun Heo wrote:
> Hello, Paul.
> 
> On Fri, Jul 20, 2012 at 02:52:07PM -0700, Paul E. McKenney wrote:
> > > Fix it by using different priorities for up and down notifiers - high
> > > priority for up operations and low priority for down operations.
> > 
> > Cool!!!
> > 
> > This certainly provides another data point in favor of running down
> > notifiers in the opposite order from up notifiers.  ;-)
> 
> Yeah, I was thinking about that.  I don't think converting CPU
> notifiers would take a lot of work in terms of both auditing and
> converting.  We only have several priorities.
> 
> > This series passes light rcutorture/hotplug testing, will be testing
> > it more.
> 
> Great!

Unfortunately, my single-processor testing did see some failures:

[    1.985859] WARNING: at /media/homes/git/linux-2.6-tip.test/kernel/workqueue.c:1953 process_one_work+0x257/0x500()
[    1.985859] Hardware name: Bochs
[    1.985859] Modules linked in:
[    1.985859] Pid: 9, comm: khelper Not tainted 3.5.0-rc5+ #1615
[    1.985859] Call Trace:
[    1.985859]  [<c10258cd>] warn_slowpath_common+0x6d/0xa0
[    1.985859]  [<c1041377>] ? process_one_work+0x257/0x500
[    1.985859]  [<c1041377>] ? process_one_work+0x257/0x500
[    1.985859]  [<c102591d>] warn_slowpath_null+0x1d/0x20
[    1.985859]  [<c1041377>] process_one_work+0x257/0x500
[    1.985859]  [<c1040a23>] ? worker_maybe_bind_and_lock.isra.25+0x63/0x80
[    1.985859]  [<c103e6f0>] ? umh_complete+0x30/0x30
[    1.985859]  [<c1041642>] process_scheduled_works+0x22/0x30
[    1.985859]  [<c1041750>] rescuer_thread+0x100/0x190
[    1.985859]  [<c1041650>] ? process_scheduled_works+0x30/0x30
[    1.985859]  [<c104884e>] kthread+0x8e/0xa0
[    1.985859]  [<c10487c0>] ? flush_kthread_worker+0xf0/0xf0
[    1.985859]  [<c167987a>] kernel_thread_helper+0x6/0xd
[    1.985859] ---[ end trace f945593f544d7041 ]---

Line 1953 is this one in process_one_work():

	WARN_ON_ONCE(!(worker->flags & (WORKER_UNBOUND | WORKER_REBIND)) &&
		     raw_smp_processor_id() != gcwq->cpu);

I confess to being puzzled, given that there is but one CPU.

My .config is attached.

							Thanx, Paul

View attachment ".config" of type "text/plain" (83341 bytes)