Hello Christophe,
On Sat, 2020-03-28 at 10:19 +, Christophe Leroy wrote:
> Hi Leonardo,
>
>
> > On 03/27/2020 03:51 PM, Leonardo Bras wrote:
> > >
> > [SNIP]
> > - If the lock is already free, it would change nothing,
> > - Otherwise, the lock will wait.
> > - Waiting cycle just got bigger.
Hello Peter,
On Mon, 2020-03-30 at 13:02 +0200, Peter Zijlstra wrote:
> do {
> > > + if (unlikely(crash_skip_spinlock))
> > > + return;
> >
> > You are adding a test that reads a global var in the middle of a so hot path
> > ? That must kill
On Fri, Mar 27, 2020 at 07:50:20AM +0100, Christophe Leroy wrote:
>
>
> Le 26/03/2020 à 23:28, Leonardo Bras a écrit :
> > 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. (
Hi Leonardo,
On 03/27/2020 03:51 PM, Leonardo Bras wrote:
Hello Christophe, thanks for the feedback.
I noticed an error in this patch and sent a v2, that can be seen here:
http://patchwork.ozlabs.org/patch/1262468/
Comments inline::
On Fri, 2020-03-27 at 07:50 +0100, Christophe Leroy wrote:
Hello Christophe, thanks for the feedback.
I noticed an error in this patch and sent a v2, that can be seen here:
http://patchwork.ozlabs.org/patch/1262468/
Comments inline::
On Fri, 2020-03-27 at 07:50 +0100, Christophe Leroy wrote:
> > @@ -142,6 +144,8 @@ static inline void arch_spin_lock(arch
Le 26/03/2020 à 23:28, Leonardo Bras a écrit :
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_log as of today)
This is a problem if the system has
oops, forgot to EXPORT_SYMBOL.
arch_spin_lock*() is used on modules.
Sending v2.
On Thu, 2020-03-26 at 19:28 -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
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_log as of today)
This is a problem if the system has kdump set up, given if it crashes
for any reason kd
