On (10/19/16 15:34), Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 03:18:36PM +0200, Petr Mladek wrote:
> > On Tue 2016-10-18 19:07:54, Peter Zijlstra wrote:
[..]
> It might make sense to go there, but allow early_console to print on the
> go, keeping synchronous output available. We would still
On (10/19/16 15:34), Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 03:18:36PM +0200, Petr Mladek wrote:
> > On Tue 2016-10-18 19:07:54, Peter Zijlstra wrote:
[..]
> It might make sense to go there, but allow early_console to print on the
> go, keeping synchronous output available. We would still
On Wed, Oct 19, 2016 at 10:53:57AM +0900, Sergey Senozhatsky wrote:
> not to miss out a DEFERRED_WARN patch set...
> //hm, I can't find it online
>
> Subject: [RFC 0/5] printk: Implement WARN_*DEFERRED()
> Message-Id: <1474992135-14777-1-git-send-email-pmla...@suse.com>
That never hit lkml,
On Wed, Oct 19, 2016 at 10:53:57AM +0900, Sergey Senozhatsky wrote:
> not to miss out a DEFERRED_WARN patch set...
> //hm, I can't find it online
>
> Subject: [RFC 0/5] printk: Implement WARN_*DEFERRED()
> Message-Id: <1474992135-14777-1-git-send-email-pmla...@suse.com>
That never hit lkml,
On Tue 2016-10-18 19:07:54, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 12:40:39AM +0900, Sergey Senozhatsky wrote:
> > Hello,
> >
> > RFC
> >
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls. The basic mechanism is pretty
On Tue 2016-10-18 19:07:54, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 12:40:39AM +0900, Sergey Senozhatsky wrote:
> > Hello,
> >
> > RFC
> >
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls. The basic mechanism is pretty
On Wed, Oct 19, 2016 at 03:18:36PM +0200, Petr Mladek wrote:
> On Tue 2016-10-18 19:07:54, Peter Zijlstra wrote:
> > The entire class of deadlocks you've missed is that console->write() is
> > a piece of crap too ;-) Even the bog standard 8250 serial console driver
> > can do wakeups.
>
> I
On Wed, Oct 19, 2016 at 03:18:36PM +0200, Petr Mladek wrote:
> On Tue 2016-10-18 19:07:54, Peter Zijlstra wrote:
> > The entire class of deadlocks you've missed is that console->write() is
> > a piece of crap too ;-) Even the bog standard 8250 serial console driver
> > can do wakeups.
>
> I
On (10/19/16 00:40), Sergey Senozhatsky wrote:
[..]
> Deadlock scenarios that printk_safe can handle:
>
> a) printk recursion from logbuf_lock spin_lock section in printk()
> printk()
> raw_spin_lock(_lock);
> WARN_ON(1);
> raw_spin_unlock(_lock);
>
> b) printk from sem->lock
On (10/19/16 00:40), Sergey Senozhatsky wrote:
[..]
> Deadlock scenarios that printk_safe can handle:
>
> a) printk recursion from logbuf_lock spin_lock section in printk()
> printk()
> raw_spin_lock(_lock);
> WARN_ON(1);
> raw_spin_unlock(_lock);
>
> b) printk from sem->lock
On (10/18/16 19:07), Peter Zijlstra wrote:
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls. The basic mechanism is pretty much the
> > same -- at the beginning of a deadlock-prone section we switch to lock-less
> > printk callback, and
On (10/18/16 19:07), Peter Zijlstra wrote:
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls. The basic mechanism is pretty much the
> > same -- at the beginning of a deadlock-prone section we switch to lock-less
> > printk callback, and
On (10/18/16 09:45), Joe Perches wrote:
> On Wed, 2016-10-19 at 00:40 +0900, Sergey Senozhatsky wrote:
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls.
>
> trivia:
>
> recursive or reentrant?
a recursive one.
printk -> {foo} -> printk
On (10/18/16 09:45), Joe Perches wrote:
> On Wed, 2016-10-19 at 00:40 +0900, Sergey Senozhatsky wrote:
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls.
>
> trivia:
>
> recursive or reentrant?
a recursive one.
printk -> {foo} -> printk
On Wed, Oct 19, 2016 at 12:40:39AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> RFC
>
> This patch set extends a lock-less NMI per-cpu buffers idea to
> handle recursive printk() calls. The basic mechanism is pretty much the
> same -- at the beginning of a deadlock-prone section
On Wed, Oct 19, 2016 at 12:40:39AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> RFC
>
> This patch set extends a lock-less NMI per-cpu buffers idea to
> handle recursive printk() calls. The basic mechanism is pretty much the
> same -- at the beginning of a deadlock-prone section
On Wed, 2016-10-19 at 00:40 +0900, Sergey Senozhatsky wrote:
> This patch set extends a lock-less NMI per-cpu buffers idea to
> handle recursive printk() calls.
trivia:
recursive or reentrant?
On Wed, 2016-10-19 at 00:40 +0900, Sergey Senozhatsky wrote:
> This patch set extends a lock-less NMI per-cpu buffers idea to
> handle recursive printk() calls.
trivia:
recursive or reentrant?
Hello,
RFC
This patch set extends a lock-less NMI per-cpu buffers idea to
handle recursive printk() calls. The basic mechanism is pretty much the
same -- at the beginning of a deadlock-prone section we switch to lock-less
printk callback, and return back to a default printk
Hello,
RFC
This patch set extends a lock-less NMI per-cpu buffers idea to
handle recursive printk() calls. The basic mechanism is pretty much the
same -- at the beginning of a deadlock-prone section we switch to lock-less
printk callback, and return back to a default printk
20 matches
Mail list logo
