[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <986cb39001ee9eb11dd546b79de9e0b4b8463d19.camel@sipsolutions.net>
Date: Thu, 25 Oct 2018 17:31:27 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Bart Van Assche <bvanassche@....org>, Tejun Heo <tj@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
"tytso@....edu" <tytso@....edu>
Subject: Re: [PATCH 1/3] kernel/workqueue: Remove lockdep annotation from
__flush_work()
On Thu, 2018-10-25 at 15:05 +0000, Bart Van Assche wrote:
> As documented in a comment in start_flush_work(), calling flush_work()
> from a multi-threaded workqueue is safe if that workqueue is not
> equipped with a rescuer. Avoid that flush_work() calls from inside a
> work item executing on such a queue trigger a lockdep complaint.
So ... not sure I understand, do you happen to have an example (at least
conceptually) that shows the problem?
Something like
workqueue WQ, works W1, W2
W1 running on WQ -> flush_work(W2) also running on WQ?
I'm willing to believe that this is a corner case I missed with the
annotations since the rescuer things are tricky, but I don't think
removing them is the right thing to do.
> Remove
> the lockdep annotation from __flush_work() because start_flush_work()
> already has such an annotation.
This part at least isn't true, there's no annotation on the work
*struct*, only one on the work *queue*.
johannes
Powered by blists - more mailing lists