From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] KVM: x86/mmu: remove unnecessary "bool shared" argument from iterators
Date: Fri, 29 Sep 2023 09:14:14 -0700 [thread overview]
Message-ID: <ZRb31g0PBR588XwK@google.com> (raw)
In-Reply-To: <6bc63f82495501f9664b7d19bd8c7ba64329d37b.camel@redhat.com>
On Thu, Sep 28, 2023, Maxim Levitsky wrote:
> У чт, 2023-09-28 у 12:29 -0400, Paolo Bonzini пише:
> > The "bool shared" argument is more or less unnecessary in the
> > for_each_*_tdp_mmu_root_yield_safe() macros. Many users check for
> > the lock before calling it; all of them either call small functions
> > that do the check, or end up calling tdp_mmu_set_spte_atomic() and
> > tdp_mmu_iter_set_spte(). Add a few assertions to make up for the
> > lost check in for_each_*_tdp_mmu_root_yield_safe(), but even this
> > is probably overkill and mostly for documentation reasons.
>
> Why not to leave the 'kvm_lockdep_assert_mmu_lock_held' but drop the shared
> argument from it? and then use lockdep_assert_held. If I am not mistaken,
> lockdep_assert_held should assert if the lock is held for read or write.
+1, I don't see any downside to asserting that mmu_lock is held when iterating.
It'll be a redundant assertion 99% of the time, but it's not like performance
matters all that much when running with lockdep enabled. And I find lockdep
assertions to be wonderful documentation.
next prev parent reply other threads:[~2023-09-29 16:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 16:29 [PATCH 0/3] KVM: x86/mmu: small locking cleanups Paolo Bonzini
2023-09-28 16:29 ` [PATCH 1/3] KVM: x86/mmu: remove unnecessary "bool shared" argument from functions Paolo Bonzini
2023-09-28 16:46 ` Maxim Levitsky
2023-09-29 16:11 ` Sean Christopherson
2023-09-28 16:29 ` [PATCH 2/3] KVM: x86/mmu: remove unnecessary "bool shared" argument from iterators Paolo Bonzini
2023-09-28 16:55 ` Maxim Levitsky
2023-09-29 16:14 ` Sean Christopherson [this message]
2023-09-28 16:29 ` [PATCH 3/3] KVM: x86/mmu: always take tdp_mmu_pages_lock Paolo Bonzini
2023-09-29 7:30 ` kernel test robot
2023-09-29 16:16 ` Sean Christopherson
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=ZRb31g0PBR588XwK@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
/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.