From: Paolo Bonzini <pbonzini@redhat.com>
To: Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
seanjc@google.com, Joel Fernandes <joel@joelfernandes.org>,
Matthew Wilcox <willy@infradead.org>,
Josh Triplett <josh@joshtriplett.org>,
rcu@vger.kernel.org, Michal Luczaj <mhal@rbox.co>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] Documentation: kvm: fix SRCU locking order docs
Date: Fri, 13 Jan 2023 10:20:23 +0100 [thread overview]
Message-ID: <d1d44f07-558c-e0ed-403e-61a854c868cb@redhat.com> (raw)
In-Reply-To: <Y8EF24o932lcshKs@boqun-archlinux>
On 1/13/23 08:18, Boqun Feng wrote:
> On Thu, Jan 12, 2023 at 07:20:48AM -0800, Paul E. McKenney wrote:
>> On Thu, Jan 12, 2023 at 08:24:16AM +0000, David Woodhouse wrote:
>>> 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!
>>
>> Unfortunately, lockdep needs to see a writer to complain, and that patch
>> just adds a reader. And adding that writer would make lockdep complain
>> about things that are perfectly fine. It should be possible to make
>> lockdep catch this sort of thing, but from what I can see, doing so
>> requires modifications to lockdep itself.
>>
>
> Please see if the follow patchset works:
>
> https://lore.kernel.org/lkml/20230113065955.815667-1-boqun.feng@gmail.com
>
> "I have been called. I must answer. Always." ;-)
It's missing an important testcase; if it passes (does not warn), then
it should work:
CPU 1 CPU 2
---------------------------- ------------------------------
mutex_lock(&m1); srcu_read_lock(&srcu1);
srcu_read_lock(&srcu1); mutex_lock(&m1);
srcu_read_unlock(&srcu1); mutex_unlock(&m1);
mutex_unlock(&m1); srcu_read_unlock(&srcu1);
This is the main difference, lockdep-wise, between SRCU and an rwlock.
Paolo
next prev parent reply other threads:[~2023-01-13 9:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 18:30 [PATCH] Documentation: kvm: fix SRCU locking order docs Paolo Bonzini
2023-01-12 8:24 ` David Woodhouse
2023-01-12 15:20 ` Paul E. McKenney
2023-01-13 7:18 ` Boqun Feng
2023-01-13 9:20 ` Paolo Bonzini [this message]
2023-01-13 10:33 ` David Woodhouse
2023-01-13 11:03 ` David Woodhouse
2023-01-13 22:26 ` Michal Luczaj
2023-01-14 0:02 ` Boqun Feng
2023-01-16 17:37 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d1d44f07-558c-e0ed-403e-61a854c868cb@redhat.com \
--to=pbonzini@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=dwmw2@infradead.org \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=seanjc@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.