linux-kernel - Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep

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] [day] [month] [year] [list]

Message-ID: <20171025114938.GA3223@X58A-UD3R>
Date:   Wed, 25 Oct 2017 20:49:38 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Bart Van Assche <Bart.VanAssche@....com>
Cc:     "mingo@...nel.org" <mingo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "hch@...radead.org" <hch@...radead.org>,
        "amir73il@...il.com" <amir73il@...il.com>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "darrick.wong@...cle.com" <darrick.wong@...cle.com>,
        "johannes.berg@...el.com" <johannes.berg@...el.com>,
        "max.byungchul.park@...il.com" <max.byungchul.park@...il.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "idryomov@...il.com" <idryomov@...il.com>,
        "tj@...nel.org" <tj@...nel.org>,
        "kernel-team@....com" <kernel-team@....com>,
        "david@...morbit.com" <david@...morbit.com>
Subject: Re: [RESEND PATCH 1/3] completion: Add support for initializing
 completion with lockdep_map

On Wed, Oct 25, 2017 at 07:07:06AM +0000, Bart Van Assche wrote:
> > Please, point out logical problems of cross-release than saying it's
> > impossbile according to the paper.
> 
> Isn't that the same? If it's impossible to use lock-graphs for detecting deadlocks
> in programs that use mutexes, semaphores and condition variables without triggering
> false positives that means that every approach that tries to detect deadlocks and
> that is based on lock graphs, including cross-release, must report false positives
> for certain programs.

Right. That's why I'm currently trying to assign lock classes properly
where false positives were reported. You seems to say there is another
cause of false positives. If yes, please let me know what it is. If you
do with an example, it would be more helpful for me to understand you.