linux-kernel - Re: [PATCH] clockevent: on resume program the next oneshot tick with the next actual event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49CAC0D6.3040301@goop.org>
Date:	Wed, 25 Mar 2009 16:40:06 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	"Alex.Zeffertt" <Alex.Zeffertt@...rix.com>, stable@...nel.org
Subject: Re: [PATCH] clockevent: on resume program the next oneshot tick	with
 the next actual event

Ian Campbell wrote:
> Hmm, yes I think so too. I misread tick_dev_program_event(), it seems
> like it Does The Right Thing and I do see the Xen set_next_event hook
> get called which I thought wasn't getting called earlier.
>
> Turns out the virtual timer IRQ isn't getting reinitialised before
> tick_oneshot_resume runs so we are just missing the interrupt, doh!
>   

While that ordering is a bug, I'm still not sure it completely explains 
what we're seeing here.

In drivers/xen/manage.c:do_suspend() we call clock_was_set(), which has 
the specific effect of causing all the timer events to get retriggered 
on all cpus.  This is necessary because we don't unplug/replug all the 
cpus, and the normal sysdev_resume() timer resume only resumes the 
current cpu (which is cpu 0 in this case).  It also deals with the 
clocksource timebase shifting, as it will over suspend/resume (esp 
suspend/reboot/resume, or suspend/migrate/resume).  Your patch will only 
re-trigger the next cpu0 timer event, and leave the rest hanging without 
a next event.

So the question is why does your patch help?

I'm seeing much worse symptoms on my test machine: the resumed domain is 
just sitting there spinning dead with 100% cpu use.  I don't know if 
this is related or something else.

    J

> Subject: xen: resume interrupts before system devices.
>
> otherwise the first timer interrupt after resume is missed and we never
> get another.
>
> Signed-off-by: Ian Campbell <ian.campbell@...rix.com>
>
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index 0489ea2..5269bb4 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -68,15 +68,15 @@ static int xen_suspend(void *data)
>  	gnttab_resume();
>  	xen_mm_unpin_all();
>  
> -	sysdev_resume();
> -	device_power_up(PMSG_RESUME);
> -
>  	if (!*cancelled) {
>  		xen_irq_resume();
>  		xen_console_resume();
>  		xen_timer_resume();
>  	}
>  
> +	sysdev_resume();
> +	device_power_up(PMSG_RESUME);
> +
>  	return 0;
>  }
>  
>
> Ian.
>
>
>
>   
>>     J
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>     
>
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/