Re: [RFC PATCH v4 01/13] ktask: add documentation

Peter Zijlstra
2018-11-07T10:27:52Z

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().