|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] serialize suspend-resume process
Keir Fraser wrote: On 31/7/08 14:04, "BVK Chaitanya" <bayapuneni_chaitanya@xxxxxxxxxxxx> wrote:With suspend event channel in place, i see that suspend request doesn't go through the shutdown_handler function when suspend is triggered over event channel.Oh, I agree that the shutdown_handler() can be re-entered! But it will *not* trigger multiple invocations of xen_suspend() -- note it stores away the suspend request by performing xchg(&shutting_down, ...) but it does *not* immediately trigger a suspend unless old_state==SHUTDOWN_INVALID (in which case there is no active current invocation of xen_suspend()).
In my tree there are two shutdown_handler functions.
shutdown_handler
__shutdown_handler
First one is called through xenbus interface and ensures that
xen_suspend is serialized. I agree about this.
Second one is called through suspend_int (handler for suspend event channel) as below:
static irqreturn_t suspend_int(int irq, void* dev_id,
struct pt_regs *ptregs)
{
shutting_down = SHUTDOWN_SUSPEND;
schedule_work(&shutdown_work);
return IRQ_HANDLED;
}
where shutdown_work & its callback are:
static DECLARE_WORK(shutdown_work, __shutdown_handler, NULL);
static void __shutdown_handler(void *unused)
{
int err;
err = kernel_thread((shutting_down == SHUTDOWN_SUSPEND) ?
xen_suspend : shutdown_process,
NULL, CLONE_FS | CLONE_FILES);
if (err < 0) {
printk(KERN_WARNING "Error creating shutdown"
" process (%d): "
"retrying...\n", -err);
schedule_delayed_work(&shutdown_work, HZ/2);
}
}
This second function creates a thread and calls xen_suspend without
looking for shutting_down variable's value.
I will check my tree again and will get back to you. -- bvk-chaitanya _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |