linux-kernel - Re: [PATCH] Documentation: kvm: fix SRCU locking order docs

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: <a14a13a690277d4cc95a4b26aa2d9a4d9b392a74.camel@infradead.org>
Date:   Thu, 12 Jan 2023 08:24:16 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Cc:     seanjc@...gle.com, Joel Fernandes <joel@...lfernandes.org>,
        Matthew Wilcox <willy@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Josh Triplett <josh@...htriplett.org>, rcu@...r.kernel.org,
        Michal Luczaj <mhal@...x.co>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] Documentation: kvm: fix SRCU locking order docs

On Wed, 2023-01-11 at 13:30 -0500, Paolo Bonzini wrote:
> 
> +- ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
> +  for kvm->lock, vcpu->mutex and kvm->slots_lock.  These locks _cannot_
> +  be taken inside a kvm->srcu read-side critical section; that is, the
> +  following is broken::
> +
> +      srcu_read_lock(&kvm->srcu);
> +      mutex_lock(&kvm->slots_lock);
> +

"Don't tell me. Tell lockdep!"

Did we conclude in
https://lore.kernel.org/kvm/122f38e724aae9ae8ab474233da1ba19760c20d2.camel@infradead.org/
that lockdep *could* be clever enough to catch a violation of this rule
by itself?

The general case of the rule would be that 'if mutex A is taken in a
read-section for SCRU B, then any synchronize_srcu(B) while mutex A is
held shall be verboten'. And vice versa.

If we can make lockdep catch it automatically, yay!

If not, I'm inclined to suggest that we have explicit wrappers of our
own for kvm_mutex_lock() which will do the check directly.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)