linux-kernel - Silencing false lockdep warning related to seq lock

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

Date:   Fri, 14 May 2021 10:52:31 -0400
From:   Joel Fernandes <joelaf@...gle.com>
To:     Boqun Feng <boqun.feng@...il.com>
Cc:     "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Silencing false lockdep warning related to seq lock

Hi Boqun,
You might have worked on such issues so I thought you're a good person to ask.

After apply Laurent's SPF patchset [1] , we're facing a large number
of (seemingly false positive) lockdep reports which are related to
circular dependencies with seq locks.

 lock(A); write_seqcount(B)
  vs.
write_seqcount(B); lock(A)

This cannot deadlock obviously. My current strategy which I hate is to
make it a raw seqcount write which bypasses lockdep. That's horrible
for obvious reasons. Do you have any tricks/patches up your sleeve to
silence these?

I suppose we still want to catch lockdep issues of the form (which
peterz chatted to me about):

 lock(A); write_seqcount(B)
  vs.
read_seqcount(B); lock(A)

which seems like it can deadlock.

I would rather make lockdep useful to catch these and not miss out on
them. Let me know what you think?

Cheers,
-Joel

[1] https://lkml.org/lkml/2019/4/16/615