[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160322065729.GE2279@X58A-UD3R>
Date: Tue, 22 Mar 2016 15:57:29 +0900
From: Byungchul Park <byungchul.park@....com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
Tejun Heo <tj@...nel.org>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async
On Tue, Mar 22, 2016 at 02:52:43PM +0900, Sergey Senozhatsky wrote:
> On (03/22/16 11:13), Byungchul Park wrote:
> [..]
>
> what about a "normal" case, when things are not going to explode printk(),
> but we have several lockups on the same lock (which is probably more
> likely than printk recursion)?
>
> suppose:
> - there are 8 CPUs on the system
> - 1 cpus owns the spin_lock for too long
> - 4 cpus are trying to lock the spin_lock w/o any success
> - so all 4 trigger spin_dump.
>
> what we have at the moment, is that all 4 CPUs will report a lockup,
> but with this static pointer only X (between 1 and 4, depending on the
> timing; on how fast spin_dump() will return (logbuf lock can
> be busy for a while); etc.) CPUs will do so.
Yes, I agree with you. If it's important to warn "lockup suspected" not
only per each lock, but also per each pair (cpu, lock), it should be
modified so that it can distinguish between cpus.
Anyway I think it's meaningful to make printing "lockup suspected" per a
meaningful unit, e.g. (cpu, lock), once.
If you agree with it, I will post it in your thread after fixing it. Or I
will do it in another thread. The reason why I ask you is because it can
solve a infinite recursion caused by newly introduced locks in yours.
Thank you for informing it,
Byungchul
>
> -ss
Powered by blists - more mailing lists