Patchwork [3.5.y.z,extended,stable] Patch "xen/time: Fix kasprintf splat when allocating timer%d IRQ" has been added to staging queue

mail settings
Submitter Luis Henriques
Date May 1, 2013, 11:33 p.m.
Message ID <>
Download mbox | patch
Permalink /patch/240829/
State New
Headers show


Luis Henriques - May 1, 2013, 11:33 p.m.
This is a note to let you know that I have just added a patch titled

    xen/time: Fix kasprintf splat when allocating timer%d IRQ

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see



From e1557b7cf8f08121f7df3da00b040e18be042ad2 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <>
Date: Tue, 16 Apr 2013 15:18:00 -0400
Subject: [PATCH] xen/time: Fix kasprintf splat when allocating timer%d IRQ

commit 7918c92ae9638eb8a6ec18e2b4a0de84557cccc8 upstream.

When we online the CPU, we get this splat:

smpboot: Booting Node 0 Processor 1 APIC 0x2
installing Xen timer for CPU 1
BUG: sleeping function called from invalid context at /home/konrad/ssd/konrad/linux/mm/slab.c:3179
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
Pid: 0, comm: swapper/1 Not tainted 3.9.0-rc6upstream-00001-g3884fad #1
Call Trace:
 [<ffffffff810c1fea>] __might_sleep+0xda/0x100
 [<ffffffff81194617>] __kmalloc_track_caller+0x1e7/0x2c0
 [<ffffffff81303758>] ? kasprintf+0x38/0x40
 [<ffffffff813036eb>] kvasprintf+0x5b/0x90
 [<ffffffff81303758>] kasprintf+0x38/0x40
 [<ffffffff81044510>] xen_setup_timer+0x30/0xb0
 [<ffffffff810445af>] xen_hvm_setup_cpu_clockevents+0x1f/0x30
 [<ffffffff81666d0a>] start_secondary+0x19c/0x1a8

The solution to that is use kasprintf in the CPU hotplug path
that 'online's the CPU. That is, do it in in xen_hvm_cpu_notify,
and remove the call to in xen_hvm_setup_cpu_clockevents.

Unfortunatly the later is not a good idea as the bootup path
does not use xen_hvm_cpu_notify so we would end up never allocating
timer%d interrupt lines when booting. As such add the check for
atomic() to continue.

Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Luis Henriques <>
 arch/x86/xen/enlighten.c | 5 ++++-
 arch/x86/xen/time.c      | 6 +++++-
 2 files changed, 9 insertions(+), 2 deletions(-)



diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 18b55fa..0b4f9c7 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1533,8 +1533,11 @@  static int __cpuinit xen_hvm_cpu_notify(struct notifier_block *self,
 	switch (action) {
-		if (xen_have_vector_callback)
+		if (xen_have_vector_callback) {
+			if (xen_feature(XENFEAT_hvm_safe_pvclock))
+				xen_setup_timer(cpu);
+		}
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..054cc01 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -497,7 +497,11 @@  static void xen_hvm_setup_cpu_clockevents(void)
 	int cpu = smp_processor_id();
-	xen_setup_timer(cpu);
+	/*
+	 * xen_setup_timer(cpu) - snprintf is bad in atomic context. Hence
+	 * doing it xen_hvm_cpu_notify (which gets called by smp_init during
+	 * early bootup and also during CPU hotplug events).
+	 */