From: Don Zickus <dzickus@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-tip-commits@vger.kernel.org,
Yinghai Lu <yinghai@kernel.org>,
mingo@elte.hu, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
tglx@linutronix.de, vgoyal@redhat.com
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path
Date: Mon, 20 Feb 2012 10:14:19 -0500 [thread overview]
Message-ID: <20120220151419.GU9751@redhat.com> (raw)
In-Reply-To: <m1y5s07rn3.fsf@fess.ebiederm.org>
On Fri, Feb 17, 2012 at 07:21:52PM -0800, Eric W. Biederman wrote:
> Don Zickus <dzickus@redhat.com> writes:
>
> > On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
> >>
> >> The fix with a guarantee of no more scope creep is to just disable the
> >> nmi watchdog on the kexec on panic path.
> >>
> >> Don if you have time please figure out is needed to ignore nmi's and
> >> possible record and/or report them while we boot, otherwise please cook
> >> up a patch that just disables the nmi watchdog wherever we are sending
> >> it from (the local apic or the ioapic).
> >
> > Can I keep things even simpler? The original problem was the deadlock
> > with the ioapic lock. We fixed that by removing the call to
> > disable_IO_APIC(). Can we just leave the disable_local_APIC calls in
> > there for now? Is there any real harm?
>
> > All this rewrite is going to take time which will delay fixing a current
> > problem with kexec on panic, the ioapic deadlock.
>
> Hmm.
>
> My apologies I just realized that we can not disable the nmi watchdog
> safely in all cases. To avoid the deadlock we fundamentally can not
> write to the io_apic, because the locks are the io_apic write path.
> The nmi watchdog can be sourced from either the local apics or the
> io_apics. To disable the nmi_watchdog we need at least potentially
> to write io_apic.
I am curious where you see the nmi watchdog being sourced from the ioapic?
I thought I removed that code 3 or 4 releases ago.
>
> So it appears to me that the only reasonable and robust thing we can
> do is to ignore nmis in the kexec on panic path.
>
> So it looks to me that the only path forward at this point is to fix
> the other bug where an unexpected nmi will kill the kexec on panic boot.
>
> I just took a look at the code in /sbin/kexec and that code does not in
> fact change the idt except when we switch to 16bit mode, which we
> definitely do not do in the kexec on panic case. So it appears that we
> don't need to coordinate an /sbin/kexec release with a kernel release to
> ignore nmis.
>
> In fact it looks like we only need to fix the interrupt descriptors
> loaded in machine_kexec_64.c and head64.c to ignore nmis.
>
> At which point we will have fixed two bugs and have a much more reliable
> kexec on panic implementation.
Ok. I'll talk with Vivek about how the can be implemented.
Cheers.
Don
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Don Zickus <dzickus@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
torvalds@linux-foundation.org, kexec@lists.infradead.org,
vgoyal@redhat.com, akpm@linux-foundation.org, tglx@linutronix.de,
mingo@elte.hu, linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path
Date: Mon, 20 Feb 2012 10:14:19 -0500 [thread overview]
Message-ID: <20120220151419.GU9751@redhat.com> (raw)
In-Reply-To: <m1y5s07rn3.fsf@fess.ebiederm.org>
On Fri, Feb 17, 2012 at 07:21:52PM -0800, Eric W. Biederman wrote:
> Don Zickus <dzickus@redhat.com> writes:
>
> > On Fri, Feb 17, 2012 at 04:41:01AM -0800, Eric W. Biederman wrote:
> >>
> >> The fix with a guarantee of no more scope creep is to just disable the
> >> nmi watchdog on the kexec on panic path.
> >>
> >> Don if you have time please figure out is needed to ignore nmi's and
> >> possible record and/or report them while we boot, otherwise please cook
> >> up a patch that just disables the nmi watchdog wherever we are sending
> >> it from (the local apic or the ioapic).
> >
> > Can I keep things even simpler? The original problem was the deadlock
> > with the ioapic lock. We fixed that by removing the call to
> > disable_IO_APIC(). Can we just leave the disable_local_APIC calls in
> > there for now? Is there any real harm?
>
> > All this rewrite is going to take time which will delay fixing a current
> > problem with kexec on panic, the ioapic deadlock.
>
> Hmm.
>
> My apologies I just realized that we can not disable the nmi watchdog
> safely in all cases. To avoid the deadlock we fundamentally can not
> write to the io_apic, because the locks are the io_apic write path.
> The nmi watchdog can be sourced from either the local apics or the
> io_apics. To disable the nmi_watchdog we need at least potentially
> to write io_apic.
I am curious where you see the nmi watchdog being sourced from the ioapic?
I thought I removed that code 3 or 4 releases ago.
>
> So it appears to me that the only reasonable and robust thing we can
> do is to ignore nmis in the kexec on panic path.
>
> So it looks to me that the only path forward at this point is to fix
> the other bug where an unexpected nmi will kill the kexec on panic boot.
>
> I just took a look at the code in /sbin/kexec and that code does not in
> fact change the idt except when we switch to 16bit mode, which we
> definitely do not do in the kexec on panic case. So it appears that we
> don't need to coordinate an /sbin/kexec release with a kernel release to
> ignore nmis.
>
> In fact it looks like we only need to fix the interrupt descriptors
> loaded in machine_kexec_64.c and head64.c to ignore nmis.
>
> At which point we will have fixed two bugs and have a much more reliable
> kexec on panic implementation.
Ok. I'll talk with Vivek about how the can be implemented.
Cheers.
Don
next prev parent reply other threads:[~2012-02-20 15:14 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-11 23:09 [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path tip-bot for Don Zickus
2012-02-12 1:04 ` Yinghai Lu
2012-02-12 1:04 ` Yinghai Lu
2012-02-12 3:13 ` Eric W. Biederman
2012-02-12 3:13 ` Eric W. Biederman
2012-02-12 4:17 ` Yinghai Lu
2012-02-12 4:17 ` Yinghai Lu
2012-02-13 12:52 ` Eric W. Biederman
2012-02-13 12:52 ` Eric W. Biederman
2012-02-13 16:51 ` Yinghai Lu
2012-02-13 16:51 ` Yinghai Lu
2012-02-13 18:16 ` Yinghai Lu
2012-02-13 18:16 ` Yinghai Lu
2012-02-16 17:27 ` Don Zickus
2012-02-16 17:27 ` Don Zickus
2012-02-16 21:53 ` Yinghai Lu
2012-02-16 21:53 ` Yinghai Lu
2012-02-16 21:56 ` Don Zickus
2012-02-16 21:56 ` Don Zickus
2012-02-17 3:38 ` Eric W. Biederman
2012-02-17 3:38 ` Eric W. Biederman
2012-02-17 12:41 ` Eric W. Biederman
2012-02-17 12:41 ` Eric W. Biederman
2012-02-17 15:49 ` HATAYAMA Daisuke
2012-02-17 15:49 ` HATAYAMA Daisuke
2012-02-17 20:18 ` Don Zickus
2012-02-17 20:18 ` Don Zickus
2012-02-20 5:17 ` HATAYAMA Daisuke
2012-02-20 5:17 ` HATAYAMA Daisuke
2012-02-20 15:24 ` Don Zickus
2012-02-20 15:24 ` Don Zickus
2012-02-17 19:54 ` Don Zickus
2012-02-17 19:54 ` Don Zickus
2012-02-18 3:21 ` Eric W. Biederman
2012-02-18 3:21 ` Eric W. Biederman
2012-02-20 15:14 ` Don Zickus [this message]
2012-02-20 15:14 ` Don Zickus
2012-02-21 8:01 ` Eric W. Biederman
2012-02-21 8:01 ` Eric W. Biederman
2012-02-21 13:59 ` Don Zickus
2012-02-21 13:59 ` Don Zickus
2012-02-29 23:19 ` Eric W. Biederman
2012-02-29 23:19 ` Eric W. Biederman
2012-03-07 10:53 ` Fernando Luis Vázquez Cao
2012-03-07 10:53 ` Fernando Luis Vázquez Cao
2012-03-07 10:54 ` [PATCH 1/2] boot: ignore early NMIs Fernando Luis Vázquez Cao
2012-03-07 10:54 ` Fernando Luis Vázquez Cao
2012-03-07 10:56 ` [PATCH 2/2] boot: add early NMI counter Fernando Luis Vázquez Cao
2012-03-07 10:56 ` Fernando Luis Vázquez Cao
2012-03-08 4:50 ` Eric W. Biederman
2012-03-08 4:50 ` Eric W. Biederman
2012-03-08 6:00 ` Fernando Luis Vázquez Cao
2012-03-08 6:00 ` Fernando Luis Vázquez Cao
2012-03-08 4:41 ` [PATCH 1/2] boot: ignore early NMIs Eric W. Biederman
2012-03-08 4:41 ` Eric W. Biederman
2012-03-08 5:53 ` Fernando Luis Vázquez Cao
2012-03-08 5:53 ` Fernando Luis Vázquez Cao
2012-03-08 16:35 ` Eric W. Biederman
2012-03-08 16:35 ` Eric W. Biederman
2012-03-09 9:31 ` Fernando Luis Vázquez Cao
2012-03-09 9:31 ` Fernando Luis Vázquez Cao
2012-03-09 9:51 ` [PATCH 1/3] boot: fortify early_idt_handlers definition Fernando Luis Vázquez Cao
2012-03-09 9:51 ` Fernando Luis Vázquez Cao
2012-03-09 9:55 ` [PATCH 2/3] boot: ignore early NMIs Fernando Luis Vázquez Cao
2012-03-09 9:55 ` Fernando Luis Vázquez Cao
2012-03-09 10:01 ` [PATCH 3/3] boot: add early NMI counter Fernando Luis Vázquez Cao
2012-03-09 10:01 ` Fernando Luis Vázquez Cao
2012-03-09 20:52 ` [PATCH 1/2] boot: ignore early NMIs H. Peter Anvin
2012-03-09 20:52 ` H. Peter Anvin
2012-03-12 5:43 ` Fernando Luis Vázquez Cao
2012-03-12 5:43 ` Fernando Luis Vázquez Cao
2012-03-12 5:49 ` H. Peter Anvin
2012-03-12 5:49 ` H. Peter Anvin
2012-03-12 6:14 ` Fernando Luis Vázquez Cao
2012-03-12 6:14 ` Fernando Luis Vázquez Cao
2012-03-12 13:36 ` Vivek Goyal
2012-03-12 13:36 ` Vivek Goyal
2012-03-12 19:02 ` Eric W. Biederman
2012-03-12 19:02 ` Eric W. Biederman
2012-03-12 19:58 ` Vivek Goyal
2012-03-12 19:58 ` Vivek Goyal
2012-03-12 20:02 ` H. Peter Anvin
2012-03-12 20:02 ` H. Peter Anvin
2012-03-12 18:40 ` H. Peter Anvin
2012-03-12 18:40 ` H. Peter Anvin
2012-03-12 20:01 ` Eric W. Biederman
2012-03-12 20:01 ` Eric W. Biederman
2012-03-12 20:04 ` H. Peter Anvin
2012-03-12 20:04 ` H. Peter Anvin
2012-03-12 20:16 ` H. Peter Anvin
2012-03-12 20:16 ` H. Peter Anvin
2012-03-13 2:11 ` Fernando Luis Vázquez Cao
2012-03-13 2:11 ` Fernando Luis Vázquez Cao
2012-03-13 13:33 ` Don Zickus
2012-03-13 13:33 ` Don Zickus
2012-03-15 0:43 ` Simon Horman
2012-03-15 0:43 ` Simon Horman
2012-03-13 1:43 ` Fernando Luis Vázquez Cao
2012-03-13 1:43 ` Fernando Luis Vázquez Cao
2012-03-12 14:41 ` Don Zickus
2012-03-12 14:41 ` Don Zickus
2012-03-07 15:50 ` [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path Vivek Goyal
2012-03-07 15:50 ` Vivek Goyal
2012-03-07 18:27 ` Yinghai Lu
2012-03-07 18:27 ` Yinghai Lu
2012-03-08 1:29 ` Fernando Luis Vázquez Cao
2012-03-08 1:29 ` Fernando Luis Vázquez Cao
2012-03-09 0:59 ` HATAYAMA Daisuke
2012-03-09 0:59 ` HATAYAMA Daisuke
2012-03-09 2:48 ` Eric W. Biederman
2012-03-09 2:48 ` Eric W. Biederman
2012-02-12 11:12 ` Ingo Molnar
2012-02-12 11:12 ` Ingo Molnar
2012-02-13 15:28 ` Don Zickus
2012-02-13 15:28 ` Don Zickus
2012-02-13 16:52 ` Yinghai Lu
2012-02-13 16:52 ` Yinghai Lu
2012-02-13 22:12 ` Don Zickus
2012-02-13 22:12 ` Don Zickus
2012-02-13 22:51 ` Don Zickus
2012-02-13 22:51 ` Don Zickus
2012-02-16 2:53 ` Don Zickus
2012-02-16 2:53 ` Don Zickus
2012-02-16 18:43 ` Yinghai Lu
2012-02-16 18:43 ` Yinghai Lu
2012-02-16 21:41 ` Don Zickus
2012-02-16 21:41 ` Don Zickus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120220151419.GU9751@redhat.com \
--to=dzickus@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.