[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/3] x86/mm-locks: apply a bias to lock levels for control domain
On Mon, Dec 24, 2018 at 09:04:35AM +0100, Roger Pau Monné wrote: > On Fri, Dec 21, 2018 at 06:37:32PM +0000, George Dunlap wrote: > > > > > > > On Dec 21, 2018, at 9:41 AM, Roger Pau Monne <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. > > > > > > 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> > > > > Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> > > > > …but given the nature of the change, I’d like to see it pass at least one > > ad-hoc osstest run before it gets checked in. (That probably means you’ll > > have to chase someone else to do that.) > > Thanks! > > I have the results of an ad-hoc osstest flight with the change: > > http://logs.test-lab.xenproject.org/osstest/logs/131498/ > > It doesn't looks like there are any regressions. Given the flight is green and George is likely to be on vacation ATM. I will commit this patch at some point. Wei. > > Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |