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: <1238003202.3691.174.camel@zakaz.uk.xensource.com>
Date:	Wed, 25 Mar 2009 17:46:42 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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

On Wed, 2009-03-25 at 10:19 -0700, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > When resuming a Xen domU we were seeing an issue where the timer ticks never
> > seemed to start up again. This was with CONFIG_NO_HZ=y, the Xen clocksource
> > has CLOCK_EVT_FEAT_ONESHOT but not CLOCK_EVT_FEAT_PERIODIC.
> >
> > The issue is that on resume tick_resume_oneshot() tries to program an event for
> > "now", e.g.
> > 	tick_program_event(ktime_get(), 1);
> >
> > However further down the call chain tick_dev_program_event() then compares that
> >   
> Where's that?  Do you mean in clockevents_program_event():
> 
> 	delta = ktime_to_ns(ktime_sub(expires, now));
> 
> 	if (delta <= 0)
> 		return -ETIME;
> 
> 
> ?

Yes that's the one.

> > With this fix I can successfully resume a Xen domain.
> >   
> 
> That's good, but I think there's more going on here.

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!

---

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/