Re: [PATCH v3 7/8] KVM: x86/mmu: Protect rmaps independently with SRCU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/05/21 19:45, Sean Christopherson wrote:

---------
Currently, rmaps are always allocated and published together with a new
memslot, so the srcu_dereference for the memslots array already ensures that
the memory pointed to by slots->arch.rmap is zero at the time
slots->arch.rmap.  However, they still need to be accessed in an SRCU
read-side critical section, as the whole memslot can be deleted outside
SRCU.
--------
I disagree, sprinkling random and unnecessary __rcu/SRCU annotations does more
harm than good.  Adding the unnecessary tag could be quite misleading as it
would imply the rmap pointers can_change_  independent of the memslots.

Similary, adding rcu_assign_pointer() in alloc_memslot_rmap() implies that its
safe to access the rmap after its pointer is assigned, and that's simply not
true since an rmap array can be freed if rmap allocation for a different memslot
fails.  Accessing the rmap is safe if and only if all rmaps are allocated, i.e.
if arch.memslots_have_rmaps is true, as you pointed out.

This about freeing is a very good point.

Furthermore, to actually gain any protection from SRCU, there would have to be
an synchronize_srcu() call after assigning the pointers, and that _does_  have an
associated.

... but this is incorrect (I was almost going to point out the below in my reply to Ben, then decided I was pointing out the obvious; lesson learned).

synchronize_srcu() is only needed after *deleting* something, which in this case is done as part of deleting the memslots---it's perfectly fine to batch multiple synchronize_*() calls given how expensive some of them are.

(BTW an associated what?)

So they still count as RCU-protected in my opinion, just because reading them outside SRCU is a big no and ought to warn (it's unlikely that it happens with rmaps, but then we just had 2-3 bugs like this being reported in a short time for memslots so never say never). However, rcu_assign_pointer is not needed because the visibility of the rmaps is further protected by the have-rmaps flag (to be accessed with load-acquire/store-release) and not just by the pointer being there and non-NULL.

Paolo

Not to mention that to truly respect the __rcu annotation, deleting
the rmaps would also have to be done "independently" with the correct
rcu_assign_pointer() and synchronize_srcu() logic.





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux