Re: [PATCH 2/5] x86/p2m: don't assert that the passed in MFN matches for a remove

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 <jbeulich@xxxxxxxx>
> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>