While investigating an issue (in a new codepath I'd introduced, as it turns
out), leaving interrupts disabled manifested as a subsequent op in the
multicall failing a check_lock() test.
The codepath would have hit the ASSERT_NOT_IN_ATOMIC on the return-to-guest
path, had it not hit the check_lock() first.
Call ASSERT_NOT_IN_ATOMIC() after each operation in the multicall, to make
failures more obvious.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: George Dunlap <george.dun...@eu.citrix.com>
CC: Jan Beulich <jbeul...@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
CC: Stefano Stabellini <sstabell...@kernel.org>
CC: Tim Deegan <t...@xen.org>
CC: Wei Liu <wei.l...@citrix.com>
CC: Julien Grall <julien.gr...@arm.com>
As with the related check_lock() patch, this only affects debug builds, so is
a very low risk change for 4.10
---
xen/common/multicall.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index c7af4e0..d98e59d 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -66,6 +66,13 @@ do_multicall(
disp = arch_do_multicall_call(mcs);
+ /*
+ * In the unlikley event that a hypercall has left interrupts,
+ * spinlocks, or other things in a bad way, continuting the multicall
+ * will typically lead to far more subtle issues to debug.
+ */
+ ASSERT_NOT_IN_ATOMIC();
+
#ifndef NDEBUG
{
/*
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
