On 01/04/2020 12:39, Jan Beulich wrote: > guest_physmap_remove_page() gets handed an MFN from the outside, yet > takes the necessary lock to prevent further changes to the GFN <-> MFN > mapping itself. While some callers, in particular guest_remove_page() > (by way of having called get_gfn_query()), hold the GFN lock already, > various others (most notably perhaps the 2nd instance in > xenmem_add_to_physmap_one()) don't. While it also is an option to fix > all the callers, deal with the issue in p2m_remove_page() instead: > Replace the ASSERT() by a conditional and split the loop into two, such > that all checking gets done before any modification would occur. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > Reviewed-by: Paul Durrant <paul.durr...@citrix.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
