linux-kernel - Re: [RFC/PATCH] debug workqueue deadlocks with lockdep

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: <1183557479.3812.24.camel@johannes.berg>
Date:	Wed, 04 Jul 2007 15:57:59 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, mingo@...e.hu,
	Thomas Sattler <tsattler@....de>
Subject: Re: [RFC/PATCH] debug workqueue deadlocks with lockdep

On Wed, 2007-07-04 at 16:52 +0400, Oleg Nesterov wrote:

> Yes. And no other work (except a barrier) can run before the caller of
> wait_on_work() is woken.

Alright, thanks. Yes, then what you proposed makes a lot of sense, I'll
implement it.

> Aha, now I see where I was confused. Yes, we can't avoid the false positives
> with flush_workqueue().
> 
> I hope this won't be a problem, because almost every usage of flush_workqueue()
> is pointless nowadays. So even if we have a false positive, it probably
> means the code needs cleanups anyway.
> 
> But see below,

[...]

> If you are going to do this, may I suggest you to make 2 separate patches?
> Exactly because we can't avoid the false positives with flush_workqueue(),
> it would be nice if we have an option to revert the 2-nd patch if there are
> too many false positives (I hope this won't happen).

I've run this patch on my system for a few days now and only seen
exactly one warning; however, it's *not* actually a *false* positive,
it's a positive but it's also perfectly possible to deadlock if the
system is loaded more than one work item is stuck on the workqueue for
some reason. Say A takes L1 and B runs without locks, and then you flush
the workqueue under L1; you'll get a real deadlock when both A and B are
actually scheduled to run!

johannes

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