[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/9] xen/time: Fix kasprintf splat when allocating timer%d IRQ line.
On Tue, 16 Apr 2013, Konrad Rzeszutek Wilk wrote: > 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. This last is not reflected in the code. Also, is it actually OK to move xen_setup_timer out of xen_hvm_setup_cpu_clockevents? xen_setup_cpu_clockevents registers xen_clock_events as clocksource and xen_clock_events is setup by xen_setup_timer so we need to make sure that the call order remains the same. > CC: stable@xxxxxxxxxxxxxxx > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > --- > 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 47d3243..ddbd54a 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -1641,8 +1641,11 @@ static int __cpuinit xen_hvm_cpu_notify(struct > notifier_block *self, > switch (action) { > case CPU_UP_PREPARE: > xen_vcpu_setup(cpu); > - if (xen_have_vector_callback) > + if (xen_have_vector_callback) { > xen_init_lock_cpu(cpu); > + if (xen_feature(XENFEAT_hvm_safe_pvclock)) > + xen_setup_timer(cpu); > + } > break; > default: > break; > 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_runstate_info(cpu); > - 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). > + */ > xen_setup_cpu_clockevents(); > } > > -- > 1.8.1.4 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |