On Thu, 19 Oct 2017, Bart Van Assche wrote:
> On Wed, 2017-10-18 at 18:38 +0900, Byungchul Park wrote:
> > Sometimes, we want to initialize completions with sparate lockdep maps
> > to assign lock classes under control. For example, the workqueue code
> > manages lockdep maps, as it can classify lockdep maps properly.
> > Provided a function for that purpose.
> >
> > Signed-off-by: Byungchul Park <byungchul.park@xxxxxxx>
> > ---
> > include/linux/completion.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/linux/completion.h b/include/linux/completion.h
> > index cae5400..182d56e 100644
> > --- a/include/linux/completion.h
> > +++ b/include/linux/completion.h
> > @@ -49,6 +49,13 @@ static inline void complete_release_commit(struct completion *x)
> > lock_commit_crosslock((struct lockdep_map *)&x->map);
> > }
> >
> > +#define init_completion_with_map(x, m) \
> > +do { \
> > + lockdep_init_map_crosslock((struct lockdep_map *)&(x)->map, \
> > + (m)->name, (m)->key, 0); \
> > + __init_completion(x); \
> > +} while (0)
>
> Are there any completion objects for which the cross-release checking is
> useful?
All of them by definition.
> Are there any wait_for_completion() callers that hold a mutex or
> other locking object?
Yes, there are also cross completion dependencies. There have been such
bugs and I expect more to be unearthed.
I really have to ask what your motiviation is to fight the lockdep coverage
of synchronization objects tooth and nail?
Thanks,
tglx
