[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] [xen master] common/multicall: Increase debugability for bad hypercalls



commit ff93dc55431517ed29c70dbff6721c6b0803acf9
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Tue Oct 31 17:07:41 2017 +0000
Commit:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CommitDate: Thu Nov 2 16:49:57 2017 +0000

    common/multicall: Increase debugability for bad hypercalls
    
    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.cooper3@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
---
 xen/common/multicall.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index c7af4e0..5a199eb 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 unlikely event that a hypercall has left interrupts,
+         * spinlocks, or other things in a bad way, continuing the multicall
+         * will typically lead to far more subtle issues to debug.
+         */
+        ASSERT_NOT_IN_ATOMIC();
+
 #ifndef NDEBUG
         {
             /*
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.