>>> On 21.12.18 at 10:41, <roger....@citrix.com> wrote: > paging_log_dirty_op function takes mm locks from a subject domain and > then attempts to perform copy to operations against the caller domain > in order to copy the result of the hypercall into the caller provided > buffer. > > This works fine when the caller is a non-paging domain, but triggers a > lock order panic when the caller is a paging domain due to the fact > that at the point where the copy to operation is performed the subject > domain paging lock is locked, and the copy operation requires > locking the caller p2m lock which has a lower level.
The term "paging domain" is rather confusing here: It's commonly used for domains with mem-paging enabled, and the relevant criteria here is the "translated" paging mode aiui. Otherwise PV domains would also need to be considered "paging" ones, when they have log-dirty mode enabled. > Fix this limitation by adding a bias to the level of control domain mm > locks, so that the lower control domain mm lock always has a level > greater than the higher unprivileged domain lock level. This allows > locking the subject domain mm locks and then locking the control > domain mm locks, while keeping the same lock ordering and the changes > mostly confined to mm-locks.h. > > Note that so far only this flow (locking a subject domain locks and > then the control domain ones) has been identified, but not all > possible code paths have been inspected. Hence this solution attempts > to be a non-intrusive fix for the problem at hand, without discarding > further changes in the future if other valid code paths are found that > require more complex lock level ordering. > > Signed-off-by: Roger Pau Monné <roger....@citrix.com> > --- > Cc: George Dunlap <george.dun...@eu.citrix.com> > Cc: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com> > Cc: Wei Liu <wei.l...@citrix.com> > Cc: Tim Deegan <t...@xen.org> > --- > Changes since v1: > - Boost only control domain mm lock levels instead of the caller. So are we deliberately retaining the breakage for non-Dom0 domains controlling another domain? I also have to admit that I'm not happy to see further proliferation of plain "int" use where "unsigned int" would really be appropriate. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
