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