linux-kernel - Re: [PATCH 0/3] Suppress false positives triggered by workqueue lockdep annotations

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]

Date:   Thu, 25 Oct 2018 17:27:28 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Bart Van Assche <bvanassche@....org>, 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>,
        "tytso@....edu" <tytso@....edu>
Subject: Re: [PATCH 0/3] Suppress false positives triggered by workqueue
 lockdep annotations

Hi Bart,

> In my tests with kernel v4.19 I noticed that several new false positive
> reports were generated by the workqueue lockdep annotations. This patch
> series addresses one of these false positives.

I tried my best to explain why they're not false positives as far as
lockdep is concerned, so I'd appreciate if you could address *why* you
actually think they are such.

I can understand that they are false positives as far as the code
*causing* this is concerned, but this isn't how lockdep works. It
generally tracks any dependency between "locks" (timers also, btw.) at
any time, to later be able to find issues.

This, however, should be solved at the places that actually show the
problem, not by making the lockdep annotations less powerful.

johannes