All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: x86@kernel.org, kexec-list <kexec@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	vgoyal@redhat.com
Subject: Re: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
Date: Tue, 31 Jan 2012 17:27:51 -0500	[thread overview]
Message-ID: <20120131222751.GE5650@redhat.com> (raw)
In-Reply-To: <m1ipjr4jaa.fsf@fess.ebiederm.org>

On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote:
> > The problem is that although kdump tries to shutdown minimal hardware,
> > it still needs to disable the IO APIC.  This requires spinlocks which
> > may be held by another cpu.  This other cpu is being held infinitely in
> > an NMI context by kdump in order to serialize the crashing path.  Instant
> > deadlock.
> 
> Can you test to see if kexec on panic still needs to disable the IO
> APIC.  Last I looked we were close if not all of the way there to not
> needing to boot the kernel in pic mode?

Ok, so you just blindly remove disable_IO_APIC from
native_machine_crash_shutdown and re-run some panic tests on various
machines?  What about the disable_IO_APIC path in native_machine_shutdown?

Also, where could I look to see if that work was done?  Is that in the
ioapic setup code?

> 
> If we can skip the ioapic disable entirely we should be much more
> robust.

Agreed.

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: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
	vgoyal@redhat.com, kexec-list <kexec@lists.infradead.org>
Subject: Re: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq
Date: Tue, 31 Jan 2012 17:27:51 -0500	[thread overview]
Message-ID: <20120131222751.GE5650@redhat.com> (raw)
In-Reply-To: <m1ipjr4jaa.fsf@fess.ebiederm.org>

On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote:
> > The problem is that although kdump tries to shutdown minimal hardware,
> > it still needs to disable the IO APIC.  This requires spinlocks which
> > may be held by another cpu.  This other cpu is being held infinitely in
> > an NMI context by kdump in order to serialize the crashing path.  Instant
> > deadlock.
> 
> Can you test to see if kexec on panic still needs to disable the IO
> APIC.  Last I looked we were close if not all of the way there to not
> needing to boot the kernel in pic mode?

Ok, so you just blindly remove disable_IO_APIC from
native_machine_crash_shutdown and re-run some panic tests on various
machines?  What about the disable_IO_APIC path in native_machine_shutdown?

Also, where could I look to see if that work was done?  Is that in the
ioapic setup code?

> 
> If we can skip the ioapic disable entirely we should be much more
> robust.

Agreed.

Cheers,
Don

  reply	other threads:[~2012-01-31 22:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31 21:25 [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq Don Zickus
2012-01-31 21:25 ` Don Zickus
2012-01-31 21:37 ` Vivek Goyal
2012-01-31 21:37   ` Vivek Goyal
2012-01-31 22:08 ` Eric W. Biederman
2012-01-31 22:08   ` Eric W. Biederman
2012-01-31 22:27   ` Don Zickus [this message]
2012-01-31 22:27     ` Don Zickus
2012-01-31 22:38     ` Eric W. Biederman
2012-01-31 22:38       ` Eric W. Biederman
2012-02-01 23:04       ` Don Zickus
2012-02-01 23:04         ` Don Zickus
2012-02-02  1:34         ` Eric W. Biederman
2012-02-02  1:34           ` Eric W. Biederman
2012-02-02 15:33           ` Don Zickus
2012-02-02 15:33             ` Don Zickus
2012-02-02 17:45           ` Don Zickus
2012-02-02 17:45             ` Don Zickus
2012-02-20 15:20 ` Seiji Aguchi
2012-02-20 15:20   ` Seiji Aguchi

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=20120131222751.GE5650@redhat.com \
    --to=dzickus@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=x86@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.