linux-kernel - Re: single-threaded wq lockdep is broken

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:   Wed, 31 May 2017 21:15:58 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Tejun Heo <tj@...nel.org>
Cc:     Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: single-threaded wq lockdep is broken

Hi Tejun,

> On Sun, May 28, 2017 at 09:33:13PM +0200, Johannes Berg wrote:
> > I suspect this is a long-standing bug introduced by all the pool
> > rework
> > you did at some point, but I don't really know nor can I figure out
> > how
> > to fix it right now. I guess it could possibly also be a lockdep
> > issue,
> > or an issue in how it's used, but I definitely know that this used
> > to
> > work (i.e. warn) back when I introduced the lockdep checking to the
> > WQ
> 
> Hah, didn't know this worked.

Ah, it was nice when I made this work - but you won't believe the
number of times I had to answer the question "what does this mean?" :-)

> So, it used to always create dependency between work items on
> singlethread workqueues according to their queeing order?  It
> shouldn't be difficult to fix.  I'll dig through the history and see
> what happened.

No, queuing order is (was) irrelevant, and I'm not sure it should
really matter all that much, since you often can't really predict
queueing order. It used to be that this triggered a lot on the
system_wq, which of course is no longer single-threaded so I suppose it
can make progress even in situations like this?

It basically just did a dependency of wq->work, work->mutex (according
to my code) and mutex->wq due to the flush.

I think that perhaps the last dependency of mutex->wq is lost now due
to flush_work()? Or perhaps there's something with the read/write thing
that caused this issue.

johannes