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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 20/10/16 17:29, Tamas K Lengyel wrote:
> 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.

Yay locks. :-)

It would probably be helpful to have a comment there explaining the
situation, so that people in the future don't need to re-discover this
issue.

Do you want to toss together a patch adding such a comment, or shall I?

 -George

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