On Sat, Jan 25, 2025, Paolo Bonzini wrote: > On 1/25/25 00:44, Sean Christopherson wrote: > > SRCU readers would only interact with kvm_destroy_vm() from a locking perspective, > > and if that's problematic then we would already have a plethora of issues. > > Ah yeah, I missed that you cannot hold any lock when calling kvm_put_kvm(). > So the waiting side is indeed a leaf and cannot block someone else. > > Still from your patch (thanks!) I don't really like the special cases on > taking SRCU vs. kvm_lock... It really seems like a job for a mutex or rwsem. > It keeps the complexity in the one place that is different (i.e. where a > lock is taken inside the iteration) and everything else can just iterate > normally. I like the special casing, it makes the oddballs stand out, which in turn (hopefully) makes developers pause and take note. I.e. the SRCU walkers are all normal readers, the set_nx_huge_pages() "never" path is a write in disguise, and kvm_hyperv_tsc_notifier() is a very special snowflake.
