xen: fix hang on suspend.
commita111c28a5d47bc15ed6b644a0b7c69d748c1bdb2
authorIan Campbell <ian.campbell@citrix.com>
Thu, 17 Dec 2009 13:57:09 +0000 (17 13:57 +0000)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 18 Jan 2010 18:19:44 +0000 (18 10:19 -0800)
treefd46c2b14aee99aa3c570af9b2b6febe1937ebcc
parent38c4d8d579c4e752e03edcdd2e96a49787d71a3a
xen: fix hang on suspend.

commit c5cae661d6cf808b6984762f763261adf35f3eb7 upstream.

In 65f63384 "xen: improve error handling in do_suspend" I said:
    - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
      nested in the obvious way.
and changed the ordering of the calls as so:
    BEFORE AFTER
    xs_suspend dpm_suspend_noirq
    dpm_suspend_noirq xs_suspend
    *SUSPEND* *SUSPEND*
    dpm_resume_noirq dpm_resume_noirq
    xs_resume xs_resume
Clearly this is not an improvement and I was talking rubbish.

In particular the new ordering is susceptible to a hang if a xenstore write is
in progress at the point at which the suspend kicks in. When the suspend
process calls xs_suspend it tries to take the request_mutex but if a write is
in progress it could be looping in xenbus_xs.c:read_reply() waiting for
something to arrive on &xs_state.reply_list while holding the request_mutex
(taken in the caller of read_reply).

However if we have done dpm_suspend_noirq before xs_suspend then we won't get
any more xenstore interrupts and process_msg() will never be woken up to add
anything to the reply_list.

Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
fails then make sure we go through the xs_suspend_cancel() code path.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/xen/manage.c