Everywhere else gfn_t are passed into respective GFN locking macros: Do so
here as well.
Amends: 819cdc5a7301 ("x86/p2m: re-arrange {,__}put_gfn()")
Signed-off-by: Jan Beulich <[email protected]>
---
Easy to spot by adding ASSERT(!gfn_eq(g, INVALID_GFN)) to the respective
macros. While imo that should be a correct thing to do (as with
hypothetical split locks a valid GFN would really need passing in, in
order to be able to figure out which lock to use), we can't do so right
now: The lock is acquired ahead of respective checking in a number of
places, e.g. in p2m_get_gfn_type_access().
There's no clear Fixes: tag to use, I think - the problem looks to have
been introduced by the gradual conversion to gfn_t. I probably should not
have added gfn_x() in the referenced commit, to unbreak things already at
that time.
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -338,9 +338,9 @@ mfn_t p2m_get_gfn_type_access(struct p2m
void p2m_put_gfn(struct p2m_domain *p2m, gfn_t gfn)
{
- ASSERT(gfn_locked_by_me(p2m, gfn_x(gfn)));
+ ASSERT(gfn_locked_by_me(p2m, gfn));
- gfn_unlock(p2m, gfn_x(gfn), 0);
+ gfn_unlock(p2m, gfn, 0);
}
static struct page_info *get_page_from_mfn_and_type(
