On Oct 20, 2016 18:40, "George Dunlap" <george.dun...@citrix.com> wrote: > > On 20/10/16 17:29, Tamas K Lengyel wrote: > > On Oct 20, 2016 18:18, "George Dunlap" <george.dun...@citrix.com> 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.leng...@zentific.com> > >> > >> 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? >
Please do so if you can, I'm traveling at the moment so it would be a couple days before I could send a patch for that. Thanks, Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel