On Wed, Nov 07, 2018 at 11:27:52AM +0100, Peter Zijlstra wrote: > On Tue, Nov 06, 2018 at 08:51:54PM +0000, Jason Gunthorpe wrote: > > On Tue, Nov 06, 2018 at 12:34:11PM -0800, Daniel Jordan wrote: > > > > > > What isn't clear is if this calling thread is waiting or not. Only do > > > > this inheritance trick if it is actually waiting on the work. If it is > > > > not, nobody cares. > > > > > > The calling thread waits. Even if it didn't though, the inheritance trick > > > would still be desirable for timely completion of the job. > > > > Can you make lockdep aware that this is synchronous? > > > > ie if I do > > > > mutex_lock() > > ktask_run() > > mutex_lock() > > > > Can lockdep know that all the workers are running under that lock? > > > > I'm thinking particularly about rtnl_lock as a possible case, but > > there could also make some sense to hold the read side of the mm_sem > > or similar like the above. > > Yes, the normal trick is adding a fake lock to ktask_run and holding > that over the actual job. See lock_map* in flush_workqueue() vs > process_one_work().
I'll add that for the next version.
