Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Sergey Senozhatsky]

On (01/28/16 21:48), Peter Hurley wrote:
[..]
> > yes, I proposed to add a ->reset callback to struct console
> > a while ago, and to do a console reset loop in zap_locks()
> 
> What was the patch series title? I'd like to review that.

Thanks.

it was deep in the thread where Jan Kara proposed v1 of his
printk offloading support
"Re: [PATCH 1/7] printk: Hand over printing to console if printing too long"

 http://marc.info/?l=linux-kernel&m=144976121529901

I never ended up sending this out as a separate patch. my bad.

the panic()->zap_locks() was here (well, not even a patch set):
 http://marc.info/?l=linux-kernel&m=145260677129044

> That would solve the recursive deadlock from console driver as well
> (at least with CONFIG_DEBUG_SPINLOCK) because the printk() recursion
> would zap the locks including the console driver's lock and
> at least get the last output so that we'd know there was a recursion,
> and fix it.

yes, if printk() has a chance to detect a recursion and invoke zap_locks()
(which is based on logbuf_cpu check). in my other email there is a scenario
when printk() has no such a chance -- because 'logbuf_cpu' is set to UINT_MAX
right before raw_spin_unlock(&logbuf_lock). and if debug_spin_unlock() detects
a coding error (not even a corruption) (->owner != current, or
->owner_cpu != raw_smp_processor_id()) then things are turning bad quickly.

mail: http://marc.info/?l=linux-kernel&m=145404023915268

	-ss