On Fri, May 31, 2024 at 12:18 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > On Fri, May 31, 2024 at 12:11:33PM -0700, Oliver Upton wrote: > > On Wed, May 29, 2024 at 06:05:09PM +0000, James Houghton wrote: > > > > [...] > > > > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > > > index 9e2bbee77491..eabb07c66a07 100644 > > > --- a/arch/arm64/kvm/hyp/pgtable.c > > > +++ b/arch/arm64/kvm/hyp/pgtable.c > > > @@ -1319,10 +1319,8 @@ static int stage2_age_walker(const struct kvm_pgtable_visit_ctx *ctx, > > > data->young = true; > > > > > > /* > > > - * stage2_age_walker() is always called while holding the MMU lock for > > > - * write, so this will always succeed. Nonetheless, this deliberately > > > - * follows the race detection pattern of the other stage-2 walkers in > > > - * case the locking mechanics of the MMU notifiers is ever changed. > > > + * This walk may not be exclusive; the PTE is permitted to change > > > + * from under us. > > > */ > > > if (data->mkold && !stage2_try_set_pte(ctx, new)) > > > return -EAGAIN; > > > > It is probably worth mentioning that if there was a race to update the > > PTE then the GFN is most likely young, so failing to clear AF probably > > isn't even consequential. Thanks Oliver. > > Oh, and the WARN_ON() in kvm_pgtable_stage2_test_clear_young() is bogus > now. Maybe demote it to: > > r = kvm_pgtable_walk(...); > WARN_ON_ONCE(r && r != -EAGAIN); Oh, indeed, thank you. Just to make sure -- does it make sense to retry the cmpxchg if it fails? For example, the way I have it now for x86[1], we retry the cmpxchg if the spte is still a leaf, otherwise we move on to the next one having done nothing. Does something like that make sense for arm64? [1]: https://lore.kernel.org/linux-mm/20240529180510.2295118-6-jthoughton@xxxxxxxxxx/
