Re: [Xen-devel] [PATCH v2 3/3] x86/mm-locks: apply a bias to lock levels for control domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.12.18 at 10:41, <roger.pau@xxxxxxxxxx> 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.pau@xxxxxxxxxx>
> ---
> Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> Cc: Tim Deegan <tim@xxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel