[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170905071930.h6t2f4guvmswibnv@hirez.programming.kicks-ass.net>
Date: Tue, 5 Sep 2017 09:19:30 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Byungchul Park <byungchul.park@....com>
Cc: Byungchul Park <max.byungchul.park@...il.com>,
Ingo Molnar <mingo@...nel.org>, Tejun Heo <tj@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, david@...morbit.com,
Johannes Berg <johannes@...solutions.net>, oleg@...hat.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kernel-team@....com
Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote:
> So you worry about max_active==1 ? Or you worry about pool->lock or
> about the thread setup? I'm still not sure.
So the thing about pool->lock is that its a leaf lock, we take nothing
inside it. Futhermore its a spinlock and therefore blocking things like
completions or page-lock cannot form a deadlock with it.
It is also fully isolated inside workqueue.c and easy to audit.
This is why I really can't be arsed about it.
And the whole setup stuff isn't properly preserved between works in any
case, only the first few works would ever see that history, so why
bother.
We _could_ save/restore the setup history, by doing a complete copy of
it and restoring that, but that's not what crossrelease did, and I
really don't see the point.
Powered by blists - more mailing lists