Re: Ping: [PATCH v4] x86/altp2m: p2m_altp2m_propagate_change() should honor present page order

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Feb 24, 2022 at 8:10 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 03.02.2022 14:57, Jan Beulich wrote:
> > For higher order mappings the comparison against p2m->min_remapped_gfn
> > needs to take the upper bound of the covered GFN range into account, not
> > just the base GFN. Otherwise, i.e. when dropping a mapping overlapping
> > the remapped range but the base GFN outside of that range, an altp2m may
> > wrongly not get reset.
> >
> > Note that there's no need to call get_gfn_type_access() ahead of the
> > check against the remapped range boundaries: None of its outputs are
> > needed earlier, and p2m_reset_altp2m() doesn't require the lock to be
> > held. In fact this avoids a latent lock order violation: With per-GFN
> > locking p2m_reset_altp2m() not only doesn't require the GFN lock to be
> > held, but holding such a lock would actually not be allowed, as the
> > function acquires a P2M lock.
> >
> > Local variables are moved into the more narrow scope (one is deleted
> > altogether) to help see their actual life ranges.
> >
> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > ---
> > Note that this addresses only half of the problem: get_gfn_type_access()
> > would also need invoking for all of the involved GFNs, not just the 1st
> > one.
> > ---
> > v4: Restore mistakenly dropped mfn_eq(mfn, INVALID_MFN).
>
> I think this was the only open item I needed to deal with. Any chance
> I could get an ack or R-b here, please?
>
> Thanks, Jan

Reviewed-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>