Re: [PATCH v2 6/8] KVM: Fix multiple races in gfn=>pfn cache refresh

[Paolo Bonzini]

On 4/27/22 03:40, Sean Christopherson wrote:
> +		 * Wait for mn_active_invalidate_count, not mmu_notifier_count,
> +		 * to go away, as the invalidation in the mmu_notifier event
> +		 * occurs_before_  mmu_notifier_count is elevated.
> +		 *
> +		 * Note, mn_active_invalidate_count can change at any time as
> +		 * it's not protected by gpc->lock.  But, it is guaranteed to
> +		 * be elevated before the mmu_notifier acquires gpc->lock, and
> +		 * isn't dropped until after mmu_notifier_seq is updated.  So,
> +		 * this task may get a false positive of sorts, i.e. see an
> +		 * elevated count and wait even though it's technically safe to
> +		 * proceed (becase the mmu_notifier will invalidate the cache
> +		 *_after_  it's refreshed here), but the cache will never be
> +		 * refreshed with stale data, i.e. won't get false negatives.

I am all for lavish comments, but I think this is even too detailed.  What about:

                /*
                 * mn_active_invalidate_count acts for all intents and purposes
                 * like mmu_notifier_count here; but we cannot use the latter
                 * because the invalidation in the mmu_notifier event occurs
                 * _before_ mmu_notifier_count is elevated.
                 *
                 * Note, it does not matter that mn_active_invalidate_count
                 * is not protected by gpc->lock.  It is guaranteed to
                 * be elevated before the mmu_notifier acquires gpc->lock, and
                 * isn't dropped until after mmu_notifier_seq is updated.
                 */

Paolo