Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 02/03/18 23:42, Stefano Stabellini wrote:
> On Wed, 28 Feb 2018, Julien Grall wrote:
> > Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
> > assumed the read-write lock can be taken recursively. However, this
> > assumption is wrong and will lead to deadlock when the lock is
> > contended.
> >
> > To avoid the nested lock, rework the locking in get_page_from_gva and
> > p2m_mem_access_check_and_get_page. The latter will now be called without
> > the p2m lock. The new locking in p2m_mem_accces_check_and_get_page will
> > not cover the translation of the VA to an IPA.
> >
> > This is fine because we can't promise that the stage-1 page-table have
> > changed behind our back (they are under guest control). Modification in
> > the stage-2 page-table can now happen, but I can't issue any potential
> > issue here except with the break-before-make sequence used when updating
> > page-table. gva_to_ipa may fail if the sequence is executed at the same
> > on another CPU. In that case we would fallback in the software lookup
> > path.
> >
> > Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
>
> Hi Julien,
>
> At first glance the patch looks OK, but could you please add more
> information on the recursive lock sequence that this patch is trying to
> solve? Specifically, how Xen can get into a situation where it tries to
> acquire the p2m lock twice recursively? I realize the comment at the
> bottom says "access_guest_memory_by_ipa in guest_walk_(sd|ld)" but I
> would appreciate more details. Thanks!
Good point. I will resend it with an updated commit message.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel