Re: [RFC][PATCH 3/7] printk: introduce per-cpu alt_print seq buffer

2016-09-30 Thread Petr Mladek
On Fri 2016-09-30 10:05:28, Sergey Senozhatsky wrote: > On (09/29/16 14:26), Petr Mladek wrote: > [..] > > > printk() > > > local_irq_save() > > > alt_printk_enter() > > > > We need to make sure that exit() is called on the same CPU. > > Therefore we need to disable preemption as well. > > l

Re: [RFC][PATCH 3/7] printk: introduce per-cpu alt_print seq buffer

2016-09-29 Thread Sergey Senozhatsky
On (09/29/16 14:26), Petr Mladek wrote: [..] > > printk() > > local_irq_save() > > alt_printk_enter() > > We need to make sure that exit() is called on the same CPU. > Therefore we need to disable preemption as well. local_irq_save() does this for us, we can't get sched tick or re-sched IPI,

Re: [RFC][PATCH 3/7] printk: introduce per-cpu alt_print seq buffer

2016-09-29 Thread Petr Mladek
On Tue 2016-09-27 23:22:33, Sergey Senozhatsky wrote: > This patch extends the idea of NMI per-cpu buffers to regions > that may cause recursive printk() calls and possible deadlocks. > Namely, printk() can't handle printk calls from schedule code > or printk() calls from lock debugging code (spin_

[RFC][PATCH 3/7] printk: introduce per-cpu alt_print seq buffer

2016-09-27 Thread Sergey Senozhatsky
This patch extends the idea of NMI per-cpu buffers to regions that may cause recursive printk() calls and possible deadlocks. Namely, printk() can't handle printk calls from schedule code or printk() calls from lock debugging code (spin_dump() for instance); because those may be called with `sem->l