This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] Control Interface tx tasklet

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] Control Interface tx tasklet
From: "Ross C Mcilroy" <mcilrorc@xxxxxxxxxxxxx>
Date: Wed, 20 Jul 2005 12:30:43 +0100
Delivery-date: Wed, 20 Jul 2005 11:29:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWNGs+xF+Hs5ddeS+yGWGErgYrSFg==
Thread-topic: [PATCH] Control Interface tx tasklet


Below is a patch to prevent a NULL function being called by the ctrl_if_tx_tasklet.  This should not really be necessary (although its a sensible check to make), however, I have been using the control interface, with a ctrl_if_send_message_and_get_response call and have noticed that duplicate responses (or response notifications) are sometimes recieved by this tasklet.  Since the first response resets the callback function to NULL, this results in the second response sending the instruction pointer to 0 within interupt context (which makes the kernel crash horribly in a way which is almost impossible to debug :) ).

Looking through the code, the only other use of ctrl_if_send_message_and_get_response is in netfront, and that is in the version of probe_interfaces which panics the kernel.

This patch stops the horrible crash, however it doesn't solve the problem of duplicate responses being recieved, therefore sometimes a duplicate message will introduce some kind of race condition which prevents a following response from being correctly handled (meaning ctrl_if_send_message_and_get_response blocks forever waiting for a responce which has been lost). 

If anyone has any ideas why duplicates might be sent, please let me know.



# HG changeset patch
# User rcmcilro@xxxxxxxxxxxxxxxxxxxxx
# Node ID c51d3245ce42554889cccad19c81797d4cd6c011
# Parent  afcc6c319b9ceae53ee218a0f07a932feebcf340
Fix null function execution in __cntl_if_tx_tasklet

diff -r afcc6c319b9c -r c51d3245ce42 linux-2.6-xen-sparse/arch/xen/kernel/ctrl_if.c
--- a/linux-2.6-xen-sparse/arch/xen/kernel/ctrl_if.c    Tue Jul 19 15:25:43 2005+++ b/linux-2.6-xen-sparse/arch/xen/kernel/ctrl_if.c    Tue Jul 19 15:52:39 2005@@ -141,7 +141,7 @@
                 msg->type, msg->subtype);

         /* Execute the callback handler, if one was specified. */
-        if ( msg->id != 0xFF )
+        if ( msg->id != 0xFF && *ctrl_if_txmsg_id_mapping[msg->id].fn != NULL)
                 msg, ctrl_if_txmsg_id_mapping[msg->id].id);

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] Control Interface tx tasklet, Ross C Mcilroy <=