Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

[Sergey Senozhatsky]

On (03/22/16 15:57), Byungchul Park wrote:
> 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.

well, just my opinion, I'd really prefer to have lockup reports from all of the
CPUs that have actually locked up, not on a per-lock basis. this gives better
understanding what was going on. trigger_all_cpu_backtrace() is not guaranteed
to be NMI-based, so if CPUA has detected a lockup it better report straight
ahead.

> 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.

a separate thread I think; this patch set is around different things and
does not touch spinlock_debug code, recursive printk is a problem even w/o
this patch set.

	-ss