On Fri 2016-12-23 10:46:43, Sergey Senozhatsky wrote:
> not every switch to printk_safe is "dictated" by logbuf_lock.
> down_trylock_console_sem(), for instance, takes semaphore spin_lock
> which already may be locked on the same CPU (*), so we need to be
> in safe mode:
>
> vprintk_emit()
> down
On (12/22/16 18:10), Petr Mladek wrote:
...
> There are many callers. I think that such wrappers make sense.
> I would only like to keep naming scheme similar to the classic
> locks. I mean:
>
> printk_safe_enter_irq()
> printk_safe_exit_irq()
>
> printk_safe_enter_irqsave(flags)
> printk_safe_ex
On Thu 2016-12-22 14:31:19, Sergey Senozhatsky wrote:
> Hello,
>
> On (12/21/16 23:36), Sergey Senozhatsky wrote:
> > Use printk_safe per-CPU buffers in printk recursion-prone blocks:
> > -- around logbuf_lock protected sections in vprintk_emit() and
> >console_unlock()
> > -- around down_tryl
Hello,
On (12/21/16 23:36), Sergey Senozhatsky wrote:
> Use printk_safe per-CPU buffers in printk recursion-prone blocks:
> -- around logbuf_lock protected sections in vprintk_emit() and
>console_unlock()
> -- around down_trylock_console_sem() and up_console_sem()
>
> Note that this solution
Use printk_safe per-CPU buffers in printk recursion-prone blocks:
-- around logbuf_lock protected sections in vprintk_emit() and
console_unlock()
-- around down_trylock_console_sem() and up_console_sem()
Note that this solution addresses deadlocks caused by printk()
recursive calls only. That i
5 matches
Mail list logo
