xen: explicitly create/destroy stop_machine workqueues outside suspend/resume region.
commit7a0eb0721ef8015e1d17fb1cc017179eedf8cc2c
authorIan Campbell <ian.campbell@citrix.com>
Tue, 1 Dec 2009 11:47:15 +0000 (1 11:47 +0000)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 18 Dec 2009 22:04:57 +0000 (18 14:04 -0800)
tree6d623c7c100a147345309e7f3ff5e1ff5f48fd12
parentebe5f3b81f1d3677882b5b1c382321096c7d1851
xen: explicitly create/destroy stop_machine workqueues outside suspend/resume region.

commit b4606f2165153833247823e8c04c5e88cb3d298b upstream.

I have observed cases where the implicit stop_machine_destroy() done by
stop_machine() hangs while destroying the workqueues, specifically in
kthread_stop(). This seems to be because timer ticks are not restarted
until after stop_machine() returns.

Fortunately stop_machine provides a facility to pre-create/post-destroy
the workqueues so use this to ensure that workqueues are only destroyed
after everything is really up and running again.

I only actually observed this failure with 2.6.30. It seems that newer
kernels are somehow more robust against doing kthread_stop() without timer
interrupts (I tried some backports of some likely looking candidates but
did not track down the commit which added this robustness). However this
change seems like a reasonable belt&braces thing to do.

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