RE: Re: [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

Dave Young suggested to me to explain the problem in more detail, so here is the revised commit description. The patch is now in -mm, so I copied Cc list from -mm version. Also I added Corey Minyard's Tested-by and Reviewed-by. From: Hidehiro Kawai Subject:

RE: Re: [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

Dave Young suggested to me to explain the problem in more detail, so here is the revised commit description. The patch is now in -mm, so I copied Cc list from -mm version. Also I added Corey Minyard's Tested-by and Reviewed-by. From: Hidehiro Kawai Subject: mips/panic: replace smp_send_stop()

RE: RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Here is the revised commit description reflecting Dave's comment. Cc list was copied from -mm version. From: Hidehiro Kawai Subject: x86/panic: replace smp_send_stop() with kdump friendly version in panic path This patch fixes a problem reported by Daniel Walker

RE: RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Here is the revised commit description reflecting Dave's comment. Cc list was copied from -mm version. From: Hidehiro Kawai Subject: x86/panic: replace smp_send_stop() with kdump friendly version in panic path This patch fixes a problem reported by Daniel Walker

RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi Xunlei, > From: Xunlei Pang [mailto:xp...@redhat.com] > Sent: Tuesday, September 20, 2016 4:40 PM > On 2016/08/15/ at 19:22, Hidehiro Kawai wrote: > > Hi Dave, > > > > Thank you for the review. > > > >> From: Dave Young [mailto:dyo...@redhat.com] > >> Sent: Friday, August 12, 2016 12:17 PM >

RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi Xunlei, > From: Xunlei Pang [mailto:xp...@redhat.com] > Sent: Tuesday, September 20, 2016 4:40 PM > On 2016/08/15/ at 19:22, Hidehiro Kawai wrote: > > Hi Dave, > > > > Thank you for the review. > > > >> From: Dave Young [mailto:dyo...@redhat.com] > >> Sent: Friday, August 12, 2016 12:17 PM >

RE: [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

> From: Corey Minyard [mailto:cminy...@mvista.com] > Sent: Tuesday, August 16, 2016 3:02 AM > On 08/15/2016 12:06 PM, Corey Minyard wrote: > > On 08/15/2016 06:35 AM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >> Hi Corey, > >> > >>> From: Corey Minyard [mailto:cm

RE: [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

> From: Corey Minyard [mailto:cminy...@mvista.com] > Sent: Tuesday, August 16, 2016 3:02 AM > On 08/15/2016 12:06 PM, Corey Minyard wrote: > > On 08/15/2016 06:35 AM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >> Hi Corey, > >> > >>> From: Corey Minyard [mailto:cm

RE: Re: [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi Corey, > From: Corey Minyard [mailto:cminy...@mvista.com] > Sent: Friday, August 12, 2016 10:56 PM > I'll try to test this, but I have one comment inline... Thank you very much! > On 08/11/2016 10:17 PM, Dave Young wrote: > > On 08/10/16 at 05:09pm, Hidehiro Kawai wrote: [snip] > >> diff

RE: Re: [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi Corey, > From: Corey Minyard [mailto:cminy...@mvista.com] > Sent: Friday, August 12, 2016 10:56 PM > I'll try to test this, but I have one comment inline... Thank you very much! > On 08/11/2016 10:17 PM, Dave Young wrote: > > On 08/10/16 at 05:09pm, Hidehiro Kawai wrote: [snip] > >> diff

RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi Dave, Thank you for the review. > From: Dave Young [mailto:dyo...@redhat.com] > Sent: Friday, August 12, 2016 12:17 PM > > Thanks for the update. > On 08/10/16 at 05:09pm, Hidehiro Kawai wrote: > > Daniel Walker reported problems which happens when > > crash_kexec_post_notifiers kernel

RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi Dave, Thank you for the review. > From: Dave Young [mailto:dyo...@redhat.com] > Sent: Friday, August 12, 2016 12:17 PM > > Thanks for the update. > On 08/10/16 at 05:09pm, Hidehiro Kawai wrote: > > Daniel Walker reported problems which happens when > > crash_kexec_post_notifiers kernel

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

> From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Tuesday, July 19, 2016 3:52 PM > Hi, > On 07/19/16 at 05:51am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi, > > > > > From: 'Dave Young' [mailto:dyo...@redhat.com] > > > Sent: Monday, July 18, 2016 6:02 PM

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

> From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Tuesday, July 19, 2016 3:52 PM > Hi, > On 07/19/16 at 05:51am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi, > > > > > From: 'Dave Young' [mailto:dyo...@redhat.com] > > > Sent: Monday, July 18, 2016 6:02 PM

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi, > From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Monday, July 18, 2016 6:02 PM > On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Dave, > > > > Thanks for your reply. > > > > > From: 'Dave Young' [mailto:dyo...@redhat.com] >

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi, > From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Monday, July 18, 2016 6:02 PM > On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Dave, > > > > Thanks for your reply. > > > > > From: 'Dave Young' [mailto:dyo...@redhat.com] >

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi Dave, Thanks for your reply. > From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Wednesday, July 13, 2016 11:04 AM > > On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Dave, > > > > Thanks for the comments. > > > > > From: Dav

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi Dave, Thanks for your reply. > From: 'Dave Young' [mailto:dyo...@redhat.com] > Sent: Wednesday, July 13, 2016 11:04 AM > > On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Dave, > > > > Thanks for the comments. > > > > > From: Dav

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

> From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xunlei Pang > Sent: Tuesday, July 12, 2016 3:57 PM > On 2016/07/12 at 11:56, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Xunlei, > > > > Thanks for the review. > &g

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

> From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xunlei Pang > Sent: Tuesday, July 12, 2016 3:57 PM > On 2016/07/12 at 11:56, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Hi Xunlei, > > > > Thanks for the review. > &g

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi Xunlei, Thanks for the review. > From: Xunlei Pang [mailto:xp...@redhat.com] > Sent: Tuesday, July 12, 2016 12:12 PM > On 2016/07/05 at 19:33, Hidehiro Kawai wrote: > > This patch fixes one of the problems reported by Daniel Walker > > (https://lkml.org/lkml/2015/6/24/44). > > > > If

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi Xunlei, Thanks for the review. > From: Xunlei Pang [mailto:xp...@redhat.com] > Sent: Tuesday, July 12, 2016 12:12 PM > On 2016/07/05 at 19:33, Hidehiro Kawai wrote: > > This patch fixes one of the problems reported by Daniel Walker > > (https://lkml.org/lkml/2015/6/24/44). > > > > If

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi Dave, Thanks for the comments. > From: Dave Young [mailto:dyo...@redhat.com] > Sent: Monday, July 11, 2016 5:35 PM > > On 07/05/16 at 08:33pm, Hidehiro Kawai wrote: > > This patch fixes one of the problems reported by Daniel Walker > > (https://lkml.org/lkml/2015/6/24/44). > > > > If

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

Hi Dave, Thanks for the comments. > From: Dave Young [mailto:dyo...@redhat.com] > Sent: Monday, July 11, 2016 5:35 PM > > On 07/05/16 at 08:33pm, Hidehiro Kawai wrote: > > This patch fixes one of the problems reported by Daniel Walker > > (https://lkml.org/lkml/2015/6/24/44). > > > > If

RE: [Openipmi-developer] [v3 PATCH 3/3] hpwdt: Use nmi_panic() when kernel panics in NMI handler

> From: Phil Pokorny [mailto:ppoko...@penguincomputing.com] > > While you are in drivers/watchdog/hpwdt.c replacing panic() with > nmi_panic() can you also fix a few more of the broken strings? The > Linux style guide specfiically says NOT to break strings that are user > visible because it

RE: [Openipmi-developer] [v3 PATCH 3/3] hpwdt: Use nmi_panic() when kernel panics in NMI handler

> From: Phil Pokorny [mailto:ppoko...@penguincomputing.com] > > While you are in drivers/watchdog/hpwdt.c replacing panic() with > nmi_panic() can you also fix a few more of the broken strings? The > Linux style guide specfiically says NOT to break strings that are user > visible because it

RE: [v3 PATCH 1/3] panic: Change nmi_panic from macro to function

> From: Borislav Petkov [mailto:b...@alien8.de] > On Thu, Mar 03, 2016 at 07:57:44PM +0900, Hidehiro Kawai wrote: > > Change nmi_panic() macro to a normal function for the portability. > > portability? I wanted to say encapsulating things into a function makes modules only have to know about the

RE: [v3 PATCH 1/3] panic: Change nmi_panic from macro to function

> From: Borislav Petkov [mailto:b...@alien8.de] > On Thu, Mar 03, 2016 at 07:57:44PM +0900, Hidehiro Kawai wrote: > > Change nmi_panic() macro to a normal function for the portability. > > portability? I wanted to say encapsulating things into a function makes modules only have to know about the

RE: [v2 PATCH 1/3] panic: Change nmi_panic from macro to function

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > On Wed, Mar 02, 2016 at 02:18:24PM +0100, Michal Hocko wrote: > > On Wed 02-03-16 19:36:26, Hidehiro Kawai wrote: > > [...] > > > +void nmi_panic(struct pt_regs *regs, const char *fmt, ...) > > > > Do we really need vargs? All the current

RE: [v2 PATCH 1/3] panic: Change nmi_panic from macro to function

Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > On Wed, Mar 02, 2016 at 02:18:24PM +0100, Michal Hocko wrote: > > On Wed 02-03-16 19:36:26, Hidehiro Kawai wrote: > > [...] > > > +void nmi_panic(struct pt_regs *regs, const char *fmt, ...) > > > > Do we really need vargs? All the current

RE: [PATCH 1/3] panic: Export panic_cpu and nmi_panic_self_stop

Hi Borislav, > From: Borislav Petkov [mailto:b...@alien8.de] > On Tue, Mar 01, 2016 at 10:50:37AM +0900, Hidehiro Kawai wrote: > > Export panic_cpu and nmi_panic_self_stop symbols for modules which > > use nmi_panic() macro. > > > > Signed-off-by: Hidehiro Kawai >

RE: [PATCH 1/3] panic: Export panic_cpu and nmi_panic_self_stop

Hi Borislav, > From: Borislav Petkov [mailto:b...@alien8.de] > On Tue, Mar 01, 2016 at 10:50:37AM +0900, Hidehiro Kawai wrote: > > Export panic_cpu and nmi_panic_self_stop symbols for modules which > > use nmi_panic() macro. > > > > Signed-off-by: Hidehiro Kawai > > Cc: Andrew Morton > > Cc:

RE: [PATCH 2/3] ipmi/watchdog: Use nmi_panic() when kernel panics in NMI handler

Hi Corey, Thanks for the review. > Sure, this is a good idea. > > Acked-by: Corey Minyard > > Note that nmi_panic() came in commit 1717f2096b5 (panic, x86: Fix > re-entrance problem due to panic on NMI) and then the regs field > was added in the commit you reference.

RE: [PATCH 2/3] ipmi/watchdog: Use nmi_panic() when kernel panics in NMI handler

Hi Corey, Thanks for the review. > Sure, this is a good idea. > > Acked-by: Corey Minyard > > Note that nmi_panic() came in commit 1717f2096b5 (panic, x86: Fix > re-entrance problem due to panic on NMI) and then the regs field > was added in the commit you reference. Yes. So, I'll change the

RE: [PATCH 3/3] hpwdt: Use nmi_panic() when kernel panics in NMI handler

Hi Guenter, Thanks for the review. > On 02/29/2016 05:50 PM, Hidehiro Kawai wrote: > > commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even > > if looping in NMI context") introduced nmi_panic() which prevents > > concurrent/recursive execution of panic(). It also saves registers

RE: [PATCH 3/3] hpwdt: Use nmi_panic() when kernel panics in NMI handler

Hi Guenter, Thanks for the review. > On 02/29/2016 05:50 PM, Hidehiro Kawai wrote: > > commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even > > if looping in NMI context") introduced nmi_panic() which prevents > > concurrent/recursive execution of panic(). It also saves registers

RE: Re: [V6 PATCH 1/6] panic/x86: Fix re-entrance problem due to panic on NMI

> From: Borislav Petkov [mailto:b...@alien8.de] [...] > Looks better. > > Did some comments cleanup and nmi_panic() macro reformatting so that it > is more readable and ended up applying this: Thanks a lot! Hidehiro Kawai Hitachi, Ltd. Research & Development Group > --- > From: Hidehiro Kawai

RE: Re: [V6 PATCH 1/6] panic/x86: Fix re-entrance problem due to panic on NMI

> From: Borislav Petkov [mailto:b...@alien8.de] [...] > Looks better. > > Did some comments cleanup and nmi_panic() macro reformatting so that it > is more readable and ended up applying this: Thanks a lot! Hidehiro Kawai Hitachi, Ltd. Research & Development Group > --- > From: Hidehiro Kawai

RE: Re: [V6 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast

Hi Steven, > From: Steven Rostedt [mailto:rost...@goodmis.org] > On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote: > > > + */ > > > + while (!raw_spin_trylock(_reason_lock)) > > > + poll_crash_ipi_and_callback(regs); > > > > Waaait a minute: so if we're getting NMIs

RE: Re: [V6 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast

Hi Steven, > From: Steven Rostedt [mailto:rost...@goodmis.org] > On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote: > > > + */ > > > + while (!raw_spin_trylock(_reason_lock)) > > > + poll_crash_ipi_and_callback(regs); > > > > Waaait a minute: so if we're getting NMIs

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Thu, Dec 03, 2015 at 02:01:38AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > On Wed, Dec 02, 2015 at 11:57:38AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > We can do so, but I think resetting panic_cpu always would be > > > > simpler and safer. > > >

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Thu, Dec 03, 2015 at 02:01:38AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > On Wed, Dec 02, 2015 at 11:57:38AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > We can do so, but I think resetting panic_cpu always would be > > > > simpler and safer. > > >

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> @@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs) > } > > /* Non-CPU-specific NMI: NMI sources can be processed on any CPU */ > - raw_spin_lock(_reason_lock); > + > + /* > + * Another CPU may be processing panic routines with holding > + *

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Wed, Dec 02, 2015 at 11:57:38AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > We can do so, but I think resetting panic_cpu always would be > > simpler and safer. I'll state in detail. When we call crash_kexec() without entering panic() and return from it, panic() should be ca

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

Hello Borislav, Sorry, I haven't replied to this mail yet. > On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote: ... > > +void crash_kexec(struct pt_regs *regs) > > +{ > > + int old_cpu, this_cpu; > > + > > + /* > > +* Only one CPU is allowed to execute the crash_kexec() code

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

Hello Borislav, Sorry, I haven't replied to this mail yet. > On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote: ... > > +void crash_kexec(struct pt_regs *regs) > > +{ > > + int old_cpu, this_cpu; > > + > > + /* > > +* Only one CPU is allowed to execute the crash_kexec() code

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Wed, Dec 02, 2015 at 11:57:38AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > We can do so, but I think resetting panic_cpu always would be > > simpler and safer. I'll state in detail. When we call crash_kexec() without entering panic() and return from it, panic() should be ca

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> @@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs) > } > > /* Non-CPU-specific NMI: NMI sources can be processed on any CPU */ > - raw_spin_lock(_reason_lock); > + > + /* > + * Another CPU may be processing panic routines with holding > + *

RE: [V5 PATCH 4/4] x86/apic: Introduce apic_extnmi boot option

> On Fri, Nov 20, 2015 at 06:36:50PM +0900, Hidehiro Kawai wrote: > > This patch introduces new boot option, apic_extnmi: > > > > apic_extnmi={ bsp | all | none} > > > > The default value is "bsp" and this is the current behavior; only > > BSP receives external NMI. "all" allows external NMIs to

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Wed, Nov 25, 2015 at 09:46:37AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: ... > > I prefer this, but we might want to add some more prefix or suffix. > > For example, "conditionally_run_crash_nmi_callback". > > That's unnecessary IMO. If you need t

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Wed, Nov 25, 2015 at 05:51:59AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > `Infinite loop in NMI context' can happen: > > > > > > > > a. when a cpu panics on NMI while another cpu is processing panic > > > > b. when a cpu received an ext

RE: [V5 PATCH 4/4] x86/apic: Introduce apic_extnmi boot option

> On Fri, Nov 20, 2015 at 06:36:50PM +0900, Hidehiro Kawai wrote: > > This patch introduces new boot option, apic_extnmi: > > > > apic_extnmi={ bsp | all | none} > > > > The default value is "bsp" and this is the current behavior; only > > BSP receives external NMI. "all" allows external NMIs to

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Wed, Nov 25, 2015 at 09:46:37AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: ... > > I prefer this, but we might want to add some more prefix or suffix. > > For example, "conditionally_run_crash_nmi_callback". > > That's unnecessary IMO. If you need t

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Wed, Nov 25, 2015 at 05:51:59AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > `Infinite loop in NMI context' can happen: > > > > > > > > a. when a cpu panics on NMI while another cpu is processing panic > > > > b. when a cpu received an ext

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote: > > Currently, panic() and crash_kexec() can be called at the same time. > > For example (x86 case): > > > > CPU 0: > > oops_end() > > crash_kexec() > > mutex_trylock() // acquired > > nmi_shootdown_cpus() //

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote: > > > > > + */ > > > + while (!raw_spin_trylock(_reason_lock)) > > > + poll_crash_ipi_and_callback(regs); > > > > Waaait a minute: so if we're getting NMIs broadcasted on every core but > > we're *not* crash dumping, we

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Fri, Nov 20, 2015 at 06:36:46PM +0900, Hidehiro Kawai wrote: > > nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI > > to non-panic cpus to stop them while saving their register > >...to stop them and save their register... Thanks for the correction. > >

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Fri, Nov 20, 2015 at 06:36:46PM +0900, Hidehiro Kawai wrote: > > nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI > > to non-panic cpus to stop them while saving their register > >...to stop them and save their register... Thanks for the correction. > >

RE: [V5 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote: > > > > > + */ > > > + while (!raw_spin_trylock(_reason_lock)) > > > + poll_crash_ipi_and_callback(regs); > > > > Waaait a minute: so if we're getting NMIs broadcasted on every core but > > we're *not* crash dumping, we

RE: [V5 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote: > > Currently, panic() and crash_kexec() can be called at the same time. > > For example (x86 case): > > > > CPU 0: > > oops_end() > > crash_kexec() > > mutex_trylock() // acquired > > nmi_shootdown_cpus() //

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

Hi, > On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote: > > If panic on NMI happens just after panic() on the same CPU, panic() > > is recursively called. As the result, it stalls after failing to > > acquire panic_lock. > > > > To avoid this problem, don't call panic() in NMI

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

Hi, > On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote: > > If panic on NMI happens just after panic() on the same CPU, panic() > > is recursively called. As the result, it stalls after failing to > > acquire panic_lock. > > > > To avoid this problem, don't call panic() in NMI

RE: Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

Hi, > I just have a look at this thread. I am wondering why we don't use > existing is_kdump_kernel() directly to disable external NMI if it's > in kdump kernel. Then no need to introduce another boot option "noextnmi" > which is used only for kdump kernel. As I stated in another mail, there is

RE: Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

Hi, > I just have a look at this thread. I am wondering why we don't use > existing is_kdump_kernel() directly to disable external NMI if it's > in kdump kernel. Then no need to introduce another boot option "noextnmi" > which is used only for kdump kernel. As I stated in another mail, there is

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> > By the way, I have a pending patch which expands this option like > > this: > > > > apic_extnmi={ bsp | all | none } > > > > If apic_extnmi=all is specified, external NMIs are broadcast to > > all CPUs. This raises the successful rate of kernel panic in the case > > where an external NMI

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> * Thomas Gleixner wrote: > > > Borislav, > > > > On Mon, 5 Oct 2015, Borislav Petkov wrote: > > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > That's different from my point of view. I'm not going to pass > >

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> * Thomas Gleixner <t...@linutronix.de> wrote: > > > Borislav, > > > > On Mon, 5 Oct 2015, Borislav Petkov wrote: > > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > That's different from my point of view. I'm

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> > By the way, I have a pending patch which expands this option like > > this: > > > > apic_extnmi={ bsp | all | none } > > > > If apic_extnmi=all is specified, external NMIs are broadcast to > > all CPUs. This raises the successful rate of kernel panic in the case > > where an external NMI

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Fri, 25 Sep 2015, Hidehiro Kawai wrote: > > > This patch introduces new boot option "noextnmi" which disables > > external NMI. This option is useful for the dump capture kernel > > so that an HA application or administrator wouldn't mistakenly > > shoot down the kernel by NMI. > > > >

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

Hello, Boris Sorry for the late reply. > On Mon, Oct 05, 2015 at 09:21:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > So, the problem for you is that "noextnmi" option is visible and effective > > in the first kernel, isn't it? > > No, such an option shouldn't exis

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Fri, 25 Sep 2015, Hidehiro Kawai wrote: > > > This patch introduces new boot option "noextnmi" which disables > > external NMI. This option is useful for the dump capture kernel > > so that an HA application or administrator wouldn't mistakenly > > shoot down the kernel by NMI. > > > >

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

Hello, Boris Sorry for the late reply. > On Mon, Oct 05, 2015 at 09:21:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > So, the problem for you is that "noextnmi" option is visible and effective > > in the first kernel, isn't it? > > No, such an option shouldn't exis

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > That's different from my point of view. I'm not going to pass > > some data from the first kernel to the second kernel. I'm just going to > > provide a configurable option for the second kernel to

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > That's different from my point of view. I'm not going to pass > > some data from the first kernel to the second kernel. I'm just going to > > provide a configurable option for the second kernel to

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Fri, Oct 02, 2015 at 12:58:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > On Thu, Oct 01, 2015 at 10:24:19AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > But how do we check if the starting kernel is a dump capture kernel? > > > > > > How does that fi

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Fri, Oct 02, 2015 at 12:58:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > On Thu, Oct 01, 2015 at 10:24:19AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > > But how do we check if the starting kernel is a dump capture kernel? > > > > > > How does that fi

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Thu, Oct 01, 2015 at 10:24:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > But how do we check if the starting kernel is a dump capture kernel? > > How does that first kernel pass info to the capture kernel? As I described in the previous mail, You just have t

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Thu, Oct 01, 2015 at 07:01:50AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > I suppose that a sever which uses this feature will equip a BMC > > and BMC mandatorily supports hard reset command for the server. > > If the HA clustering software detects no response from

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Thu, Oct 01, 2015 at 02:33:18AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote: > > > > This patch introduces new boot option "noextnmi" which disables > > > > external NMI. This option is

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Thu, Oct 01, 2015 at 07:01:50AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > I suppose that a sever which uses this feature will equip a BMC > > and BMC mandatorily supports hard reset command for the server. > > If the HA clustering software detects no response from

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Thu, Oct 01, 2015 at 02:33:18AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote: > > > > This patch introduces new boot option "noextnmi" which disables > > > > external NMI. This option is

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Thu, Oct 01, 2015 at 10:24:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > But how do we check if the starting kernel is a dump capture kernel? > > How does that first kernel pass info to the capture kernel? As I described in the previous mail, You just have t

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote: > > This patch introduces new boot option "noextnmi" which disables > > external NMI. This option is useful for the dump capture kernel > > so that an HA application or administrator wouldn't mistakenly > > shoot down the kernel by

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Mon, Sep 28, 2015 at 07:08:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg' > > > atomic_xchg(_cpu, -1); > > > ^ > > > > I changed to use atomic_xchg() inst

RE: [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Fri, Sep 25, 2015 at 08:28:07PM +0900, Hidehiro Kawai wrote: > > --- a/arch/x86/kernel/reboot.c > > +++ b/arch/x86/kernel/reboot.c > > @@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs) > > static nmi_shootdown_cb shootdown_callback; > > > > static atomic_t

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

> On Fri, Sep 25, 2015 at 12:13:55PM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the > > previoius discussion, but it still exists. So, I didn't change > > anything about panic_on_unrecovered_nmi. > > > >

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

> On Fri, Sep 25, 2015 at 12:13:55PM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the > > previoius discussion, but it still exists. So, I didn't change > > anything about panic_on_unrecovered_nmi. > > > >

RE: [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context

> On Fri, Sep 25, 2015 at 08:28:07PM +0900, Hidehiro Kawai wrote: > > --- a/arch/x86/kernel/reboot.c > > +++ b/arch/x86/kernel/reboot.c > > @@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs) > > static nmi_shootdown_cb shootdown_callback; > > > > static atomic_t

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> On Mon, Sep 28, 2015 at 07:08:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg' > > > atomic_xchg(_cpu, -1); > > > ^ > > > > I changed to use atomic_xchg() inst

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

> On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote: > > This patch introduces new boot option "noextnmi" which disables > > external NMI. This option is useful for the dump capture kernel > > so that an HA application or administrator wouldn't mistakenly > > shoot down the kernel by

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> Hi Hidehiro, > > [auto build test results on v4.3-rc2 -- if it's inappropriate base, please > ignore] > > config: ia64-allyesconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross >

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> Hi Hidehiro, > > [auto build test results on v4.3-rc2 -- if it's inappropriate base, please > ignore] > > config: ia64-allyesconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross >

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> Hi Hidehiro, > > [auto build test results on v4.3-rc2 -- if it's inappropriate base, please > ignore] > > config: x86_64-allnoconfig (attached as .config) > reproduce: > git checkout 0077681103150af584e5e592c0238fd010654c26 > # save the attached .config to linux build tree > make

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> Hi Hidehiro, > > [auto build test results on v4.3-rc2 -- if it's inappropriate base, please > ignore] > > config: x86_64-allnoconfig (attached as .config) > reproduce: > git checkout 0077681103150af584e5e592c0238fd010654c26 > # save the attached .config to linux build tree > make

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

Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the previoius discussion, but it still exists. So, I didn't change anything about panic_on_unrecovered_nmi. Thanks, Hidehiro Kawai Hitachi, Ltd. Research & Development Group > From: Hidehiro Kawai

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

Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the previoius discussion, but it still exists. So, I didn't change anything about panic_on_unrecovered_nmi. Thanks, Hidehiro Kawai Hitachi, Ltd. Research & Development Group > From: Hidehiro Kawai

RE: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> From: Peter Zijlstra [mailto:pet...@infradead.org] > On Mon, Aug 31, 2015 at 08:53:11AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > I understand your question. I don't intend to permit the recursive > > > call of crash_kexec() as for 'old_cpu != this_cpu' check. That is &

RE: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

Hello Peter, > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of 河合英宏 / KAWAI， > > Hi, > > > From: Peter Zijlstra [mailto:pet...@infradead.org] > > > > On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI，HI

RE: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

> From: Peter Zijlstra [mailto:pet...@infradead.org] > On Mon, Aug 31, 2015 at 08:53:11AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > I understand your question. I don't intend to permit the recursive > > > call of crash_kexec() as for 'old_cpu != this_cpu' check. That is &

RE: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

Hello Peter, > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of 河合英宏 / KAWAI， > > Hi, > > > From: Peter Zijlstra [mailto:pet...@infradead.org] > > > > On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI，HI

  1   2   3   >