Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

[Bart Van Assche]

On Mon, 2018-10-22 at 23:04 +-0200, Johannes Berg wrote:
+AD4 When lockdep was added, the networking socket locks also were (mostly)
+AD4 fine, recursion there only happened on different types of sockets. Yet,
+AD4 lockdep did in fact report issues with it, because originally they
+AD4 weren't split into different classes.
+AD4 
+AD4 Did we remove lockdep again because it was reporting a potential problem
+AD4 in the socket lock code?

I do not agree. It is accepted in the kernel community that if locks are
nested that nested locks should always be taken in the same order. There is
no agreement however that the kind of checking implemented by the +ACI-crosslock+ACI
code made sense. My understanding is that you are trying to reintroduce
through a backdoor some of the crosslock code. There is scientific evidence
that it is not possible to come up with an algorithm that flags all
potential deadlocks in programs that use completions without reporting false
positives. See e.g. Agarwal, Rahul, and Scott D. Stoller. +ACI-Run-time detection
of potential deadlocks for programs with locks, semaphores, and condition
variables.+ACI In Proceedings of the 2006 workshop on Parallel and distributed
systems: testing and debugging, pp. 51-60. ACM, 2006.
(http://citeseerx.ist.psu.edu/viewdoc/download?doi+AD0-10.1.1.436.7823+ACY-rep+AD0-rep1+ACY-type+AD0-pdf).

+AD4 As I thought I made pretty clear, the report is in fact valid.

I'm surprised that although your patch caused a deadlock to be reported while
no deadlock occurred that you keep insisting that your report is valid. I don't
understand this.

Bart.