[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 Fri, Apr 26, 2013 at 05:11:35PM +0100, Stefano Stabellini wrote: > 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. I found out that it was not needed. > > Also, is it actually OK to move xen_setup_timer out of > xen_hvm_setup_cpu_clockevents? Yes. It ends up being called earlier - in the notifier. > > 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. The order is still 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 |