Re: [Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Oct 20, 2016 18:18, "George Dunlap" <george.dunlap@xxxxxxxxxx> wrote:
>
> On 14/10/16 01:00, Tamas K Lengyel wrote:
> > Attempting to change gfn mappings with altp2m on a memory shared page results
> > in a lock-order violation (mm locking order violation: 282 > 254), which
> > crashes the hypervisor. Don't attempt to automatically unshare such pages and
> > just fall back to failing the op if the page type is not correct.
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
>
> It would be nice to try to untangle thus such that you can reasonably
> unshare a page in this circumstance; but given the point in the release
> cycle, making it return an error instead of crashing is probably the
> right thing to do.

You can unshare these pages, just have to do in a separate op so the locks are taken in the right order (memshare before altp2m). Reversing the lock order is not possible because otherwise the automatic unsharing and propagation during runtime runs into the lock order problem without the possibility of recovering. This way the user has the option to handle it gracefully here.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel