[PATCH 01/13] staging: unisys: respond to msgs post device_create

Benjamin Romer benjamin.romer at unisys.com
Thu Jul 9 17:27:41 UTC 2015


From: Tim Sell <Timothy.Sell at unisys.com>

Fix problem that prevents us from responding to any device message after
device_create.

By neglecting to NULL out pending_msg_hdr after the device_create response,
we were effectively preventing any subsequent messages to the device from
working, because device_epilog() will correctly bail out early if it sees
that pending_msg_hdr is still set non-NULL, as that is an indicator to mean
that an unanswered message is still outstanding.

This problem was discovered as part of testing IOVM service partition
recovery, because device_epilog() was in fact bailing out when it was
called from my_device_changestate(), which of course prevented us from
transitioning the device to the paused state.  However, the incorrect
behavior would occur for ANY subsequent command directed at the device,
not just for changestate.

Signed-off-by: Tim Sell <Timothy.Sell at unisys.com>
Signed-off-by: Benjamin Romer <benjamin.romer at unisys.com>
---
 drivers/staging/unisys/visorbus/visorchipset.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c b/drivers/staging/unisys/visorbus/visorchipset.c
index bb8087e..d47ec24 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2047,6 +2047,7 @@ device_create_response(struct visor_device *dev_info, int response)
 			 response);
 
 	kfree(dev_info->pending_msg_hdr);
+	dev_info->pending_msg_hdr = NULL;
 }
 
 static void
-- 
2.1.4



More information about the devel mailing list