[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160314024054.GC8074@swordfish>
Date: Mon, 14 Mar 2016 11:40:55 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Byungchul Park <byungchul.park@....com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
akpm@...ux-foundation.org, mingo@...nel.org,
linux-kernel@...r.kernel.org, akinobu.mita@...il.com, jack@...e.cz,
peter@...leysoftware.com, tglx@...utronix.de, peterz@...radead.org,
rostedt@...dmis.org
Subject: Re: [PATCH v6 2/2] printk: Make printing of spin_dump() deferred to
avoid a deadlock
Hi,
On (03/14/16 11:30), Byungchul Park wrote:
[..]
> > so can it be
> >
> > vprintk_emit()
> > __spin_dump_deferred()
> > vprintk_deferred()
> > vprintk_emit()
> > __spin_dump_deferred()
> ^^^
> can be caused by raw_spin_lock(logbug_lock)
>
> > vprintk_deferred()
>
> Yes, it can happen by raw_spin_lock(logbuf_lock) to print warning or error
> message. Are you worrying about an infinite recursion?
yes.
> 1. In the case printing warning, eventually it can fill the buffer without
> actual printing using console.
so the worry is that the CPU that spins on __spin_dump_deferred() has IRQs
disabled and `printk_pending' bit set; but IRQ may never be enabled on this
CPU.
> 2. In the case printing error, the infinite recursion can be prevented by
> debug_locks_off().
>
> Therefore, no problem.
-ss
Powered by blists - more mailing lists