From: Peter Zijlstra <peterz@infradead•org>
To: Leonardo Bras <leonardo@linux•ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation•org>,
linuxppc-dev@lists•ozlabs.org, linux-kernel@vger•kernel.org,
Alexios Zavras <alexios.zavras@intel•com>,
Paul Mackerras <paulus@samba•org>,
Thomas Gleixner <tglx@linutronix•de>,
Enrico Weigelt <info@metux•net>
Subject: Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash
Date: Wed, 1 Apr 2020 11:26:18 +0200 [thread overview]
Message-ID: <20200401092618.GW20713@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200401000020.590447-1-leonardo@linux.ibm.com>
On Tue, Mar 31, 2020 at 09:00:21PM -0300, Leonardo Bras wrote:
> During a crash, there is chance that the cpus that handle the NMI IPI
> are holding a spin_lock. If this spin_lock is needed by crashing_cpu it
> will cause a deadlock. (rtas.lock and printk logbuf_lock as of today)
>
> This is a problem if the system has kdump set up, given if it crashes
> for any reason kdump may not be saved for crash analysis.
>
> After NMI IPI is sent to all other cpus, force unlock all spinlocks
> needed for finishing crash routine.
>
> Signed-off-by: Leonardo Bras <leonardo@linux•ibm.com>
> @@ -129,6 +132,13 @@ static void crash_kexec_prepare_cpus(int cpu)
> /* Would it be better to replace the trap vector here? */
>
> if (atomic_read(&cpus_in_crash) >= ncpus) {
> + /*
> + * At this point no other CPU is running, and some of them may
> + * have been interrupted while holding one of the locks needed
> + * to complete crashing. Free them so there is no deadlock.
> + */
> + arch_spin_unlock(&logbuf_lock.raw_lock);
> + arch_spin_unlock(&rtas.lock);
> printk(KERN_EMERG "IPI complete\n");
> return;
> }
You might want to add a note to your asm/spinlock.h that you rely on
spin_unlock() unconditionally clearing a lock.
This isn't naturally true for all lock implementations. Consider ticket
locks, doing a surplus unlock will wreck your lock state in that case.
So anybody poking at the powerpc spinlock implementation had better know
you rely on this.
next prev parent reply other threads:[~2020-04-01 9:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 0:00 [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash Leonardo Bras
2020-04-01 3:07 ` kbuild test robot
2020-04-01 9:26 ` Peter Zijlstra [this message]
2020-04-01 23:53 ` Leonardo Bras
2020-04-02 11:28 ` Michael Ellerman
2020-04-03 0:37 ` Leonardo Bras
2020-04-03 6:41 ` Nicholas Piggin
2020-04-08 2:36 ` Leonardo Bras
2020-04-08 12:21 ` Michael Ellerman
2020-04-08 16:48 ` Leonardo Bras
2020-04-08 18:00 ` Leonardo Bras
2020-04-08 22:55 ` Leonardo Bras
2020-04-09 0:27 ` Paul Mackerras
2020-05-12 3:48 ` Leonardo Bras
2020-05-12 10:42 ` Michael Ellerman
2020-04-06 18:46 ` Leonardo Bras
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=20200401092618.GW20713@hirez.programming.kicks-ass.net \
--to=peterz@infradead$(echo .)org \
--cc=alexios.zavras@intel$(echo .)com \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=info@metux$(echo .)net \
--cc=leonardo@linux$(echo .)ibm.com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=paulus@samba$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox