Re: [V5 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 24-11-15 10:05:10, Steven Rostedt wrote:
> On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote:
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > index 350dfb0..480a4fd 100644
> > --- a/include/linux/kernel.h
> > +++ b/include/linux/kernel.h
> > @@ -445,6 +445,19 @@ extern int sysctl_panic_on_stackoverflow;
> >  
> >  extern bool crash_kexec_post_notifiers;
> >  
> > +extern atomic_t panic_cpu;
> > +
> > +/*
> > + * A variant of panic() called from NMI context.
> > + * If we've already panicked on this cpu, return from here.
> > + */
> > +#define nmi_panic(fmt, ...)						\
> > +	do {								\
> > +		int this_cpu = raw_smp_processor_id();			\
> > +		if (atomic_cmpxchg(&panic_cpu, -1, this_cpu) != this_cpu) \
> > +			panic(fmt, ##__VA_ARGS__);			\
> 
> Hmm,
> 
> What happens if:
> 
> 	CPU 0:				CPU 1:
> 	------				------
> 	nmi_panic();
> 
> 					nmi_panic();
> 					<external nmi>
> 					nmi_panic();

I thought that nmi_panic is called only from the nmi context. If so how
can we get a nested NMI like that?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux