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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1540243592.128590.36.camel@acm.org>
Date:   Mon, 22 Oct 2018 14:26:32 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Johannes Berg <johannes@...solutions.net>,
        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>,
        "linux-nvme @ lists . infradead . org" 
        <linux-nvme@...ts.infradead.org>
Subject: Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for
 flushing"

On Mon, 2018-10-22 at 23:04 +0200, Johannes Berg wrote:
> When lockdep was added, the networking socket locks also were (mostly)
> fine, recursion there only happened on different types of sockets. Yet,
> lockdep did in fact report issues with it, because originally they
> weren't split into different classes.
> 
> Did we remove lockdep again because it was reporting a potential problem
> 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 "crosslock"
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. "Run-time detection
of potential deadlocks for programs with locks, semaphores, and condition
variables." 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=10.1.1.436.7823&rep=rep1&type=pdf).

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