linux-kernel - Re: INFO: possible circular locking dependency at cleanup_workqueue

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, 23 May 2009 10:21:42 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: INFO: possible circular locking dependency at
 cleanup_workqueue_thread

On Sat, 2009-05-23 at 00:23 +0200, Rafael J. Wysocki wrote:

> > I just arrived at the same conclusion, heh. I can't say I understand
> > these changes though, the part about calling the platform differently
> > may make sense, but calling why disable non-boot CPUs at a different
> > place?
> 
> Because the ordering of platform callbacks and cpu[_up()|_down()] is also
> important, at least on resume.
> 
> In principle we can call device_pm_unlock() right before calling
> disable_nonboot_cpus() and take the lock again right after calling
> enable_nonboot_cpus(), if that helps.

Probably, unless the cpu_add_remove_lock wasn't a red herring after all.
I'd test, but I don't have much time today, will be travelling tomorrow
and be at UDS all week next week so I don't know when I'll get to it --
could you provide a patch and also attach it to
http://bugzilla.kernel.org/show_bug.cgi?id=13245 please? Miles (the
reporter of that bug) has been very helpful in testing before.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)