On Thu, Feb 24, 2022 at 8:10 AM Jan Beulich <jbeul...@suse.com> 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 <jbeul...@suse.com> > > --- > > 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 <ta...@tklengyel.com>
