[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1452b1d770bd6c516606e4855f348773d1fa6e59.camel@linux.ibm.com>
Date: Wed, 08 Apr 2020 15:41:37 -0300
From: Leonardo Bras <leonardo@...ux.ibm.com>
To: Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Enrico Weigelt <info@...ux.net>,
Thomas Gleixner <tglx@...utronix.de>,
Allison Randal <allison@...utok.net>,
Christophe Leroy <christophe.leroy@....fr>,
Nicholas Piggin <npiggin@...il.com>
Cc: linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] powerpc/crash: Use NMI context for printk after
crashing other CPUs
On Wed, 2020-04-08 at 22:13 +1000, Michael Ellerman wrote:
[...]
> Added context:
>
> printk(KERN_EMERG "Sending IPI to other CPUs\n");
>
> if (crash_wake_offline)
> ncpus = num_present_cpus() - 1;
>
> >
> > crash_send_ipi(crash_ipi_callback);
> > smp_wmb();
> > + printk_nmi_enter();
>
> Why did you decide to put it there, rather than at the start of
> default_machine_crash_shutdown() like I did?
>
> The printk() above could have already deadlocked if another CPU is stuck
> with the logbuf lock held.
Oh, I thought the CPUs would start crashing after crash_send_ipi(), so
only printk() after that would possibly deadlock.
I was not able to see how the printk() above would deadlock, but I see
no problem adding that at the start of the function.
Best regards,
Leonardo Bras
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists