All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: holzheu@linux.vnet.ibm.com
Cc: heiko.carstens@de.ibm.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com,
	akpm@linux-foundation.org, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: kdump: crash_kexec()-smp_send_stop() race in panic
Date: Mon, 24 Oct 2011 08:14:16 -0700	[thread overview]
Message-ID: <m1ipneifqv.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1319468137.3615.16.camel@br98xy6r> (Michael Holzheu's message of "Mon, 24 Oct 2011 16:55:37 +0200")

Michael Holzheu <holzheu@linux.vnet.ibm.com> writes:

> Hello Vivek,
>
> In our tests we ran into the following scenario:
>
> Two CPUs have called panic at the same time. The first CPU called
> crash_kexec() and the second CPU called smp_send_stop() in panic()
> before crash_kexec() finished on the first CPU. So the second CPU
> stopped the first CPU and therefore kdump failed.
>
> 1st CPU:
> panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
>
> 2nd CPU:
> panic()->crash_kexec()->kexec_mutex already held by 1st CPU
>        ->smp_send_stop()-> stop CPU 1 (stop kdump)
>
> How should we fix this problem? One possibility could be to do
> smp_send_stop() before we call crash_kexec().
>
> What do you think?

smp_send_stop is insufficiently reliable to be used before crash_kexec.

My first reaction would be to test oops_in_progress and wait until
oops_in_progress == 1 before calling smp_send_stop.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: holzheu@linux.vnet.ibm.com
Cc: Vivek Goyal <vgoyal@redhat.com>,
	akpm@linux-foundation.org, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: kdump: crash_kexec()-smp_send_stop() race in panic
Date: Mon, 24 Oct 2011 08:14:16 -0700	[thread overview]
Message-ID: <m1ipneifqv.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1319468137.3615.16.camel@br98xy6r> (Michael Holzheu's message of "Mon, 24 Oct 2011 16:55:37 +0200")

Michael Holzheu <holzheu@linux.vnet.ibm.com> writes:

> Hello Vivek,
>
> In our tests we ran into the following scenario:
>
> Two CPUs have called panic at the same time. The first CPU called
> crash_kexec() and the second CPU called smp_send_stop() in panic()
> before crash_kexec() finished on the first CPU. So the second CPU
> stopped the first CPU and therefore kdump failed.
>
> 1st CPU:
> panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
>
> 2nd CPU:
> panic()->crash_kexec()->kexec_mutex already held by 1st CPU
>        ->smp_send_stop()-> stop CPU 1 (stop kdump)
>
> How should we fix this problem? One possibility could be to do
> smp_send_stop() before we call crash_kexec().
>
> What do you think?

smp_send_stop is insufficiently reliable to be used before crash_kexec.

My first reaction would be to test oops_in_progress and wait until
oops_in_progress == 1 before calling smp_send_stop.

Eric

  reply	other threads:[~2011-10-24 15:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24 14:55 kdump: crash_kexec()-smp_send_stop() race in panic Michael Holzheu
2011-10-24 14:55 ` Michael Holzheu
2011-10-24 15:14 ` Eric W. Biederman [this message]
2011-10-24 15:14   ` Eric W. Biederman
2011-10-24 15:23   ` Américo Wang
2011-10-24 15:23     ` Américo Wang
2011-10-24 17:07     ` Eric W. Biederman
2011-10-24 17:07       ` Eric W. Biederman
2011-10-24 17:33       ` Vivek Goyal
2011-10-24 17:33         ` Vivek Goyal
2011-10-24 22:24         ` Seiji Aguchi
2011-10-24 22:24           ` Seiji Aguchi
2011-10-25  8:33           ` Michael Holzheu
2011-10-25  8:33             ` Michael Holzheu
2011-10-25  8:44       ` Michael Holzheu
2011-10-25  8:44         ` Michael Holzheu
2011-10-25 12:04         ` Eric W. Biederman
2011-10-25 12:04           ` Eric W. Biederman
2011-10-25 14:54           ` Vivek Goyal
2011-10-25 14:54             ` Vivek Goyal
2011-10-25 14:58           ` Michael Holzheu
2011-10-25 14:58             ` Michael Holzheu
2011-10-25 15:08             ` Vivek Goyal
2011-10-25 15:08               ` Vivek Goyal
2011-10-25 15:28               ` Michael Holzheu
2011-10-25 15:28                 ` Michael Holzheu
2011-10-25 15:28               ` Don Zickus
2011-10-25 15:28                 ` 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=m1ipneifqv.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=vgoyal@redhat.com \
    /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.