Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1503648

Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls
Date 2016-10-19 16:30 +0200
Message-ID <su02t-2rf-13@gated-at.bofh.it> (permalink)
References <stEOm-3Fs-11@gated-at.bofh.it> <stG3L-4JB-3@gated-at.bofh.it> <su02t-2rf-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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 wonder if all the hard problems are actually related to the console
> handling.
> 
> There are problems with the single logbuffer but these should get
> eliminated by the NMI/safe temporary per-CPU buffers.
> 
> All might be easier if we always offload the console handling
> into a kthread or so and trigger it via the minimalist
> irq_work. It would kill huge bunch of possible deadlocks.
> It will even allow to get rid of printk_deferred() and
> the uncertainty where it is needed.
> 
> The penalty would be "slightly" delayed console output. But is
> it a real problem? It should not be a big deal when everything works.
> We could always try hard when panicking. And there always
> might be a fallback with that direct early_console().

Right, so I've had to debug quite a few situations where that 'later'
simply never happens...

I agree that such a scenario is basically all the regular console
drivers are capable of though.

It might make sense to go there, but allow early_console to print on the
go, keeping synchronous output available. We would still need the logbuf
to become NMI safe wrt adding entries though.

It would however place hard requirements of early_console
implementations; already violated by for instance the USB3-debug-port
implementation I just looked at:

  lkml.kernel.org/r/20161019130943.GA3175@twins.programming.kicks-ass.net

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-18 17:50 +0200
  [RFC][PATCHv3 5/6] printk: use printk_safe buffers Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-18 17:50 +0200
  [RFC][PATCHv3 2/6] printk: rename nmi.c and exported api Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-18 17:50 +0200
    Re: [RFC][PATCHv3 2/6] printk: rename nmi.c and exported api Steven Rostedt <rostedt@goodmis.org> - 2016-10-18 18:50 +0200
      Re: [RFC][PATCHv3 2/6] printk: rename nmi.c and exported api Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-19 04:00 +0200
  [RFC][PATCHv3 6/6] printk: remove zap_locks() function Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-18 17:50 +0200
  [RFC][PATCHv3 4/6] printk: report lost messages in printk safe/nmi contexts Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-18 17:50 +0200
  Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Joe Perches <joe@perches.com> - 2016-10-18 18:50 +0200
    Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-19 03:20 +0200
  Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Peter Zijlstra <peterz@infradead.org> - 2016-10-18 19:10 +0200
    Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-19 04:00 +0200
      Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Peter Zijlstra <peterz@infradead.org> - 2016-10-19 18:20 +0200
    Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Peter Zijlstra <peterz@infradead.org> - 2016-10-19 16:30 +0200
      Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-20 15:20 +0200
    Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Petr Mladek <pmladek@suse.com> - 2016-10-19 16:40 +0200
  Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()  recursive calls Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-19 06:40 +0200

csiph-web