Re: printk: preempt_disable with long time resulting in softlockup/RCU stall issues

[Steven Rostedt]

On Wed, 08 Jul 2015 10:35:29 -0700
Joe Perches <joe@xxxxxxxxxxx> wrote:

> On Wed, 2015-07-08 at 19:04 +0200, Luis R. Rodriguez wrote:
> > On Wed, Jul 08, 2015 at 05:08:35PM +0800, Gavin Hu wrote:
> > > Hi,
> > > 
> > > Yes. We should disable the printk_limit feature when panic to avoid missing
> > > messages.
> > 
> > Sounds like you have been looking into it and have a good idea of what you
> > want to do, why not try it and send some RFC patches ?
> > 
> > While at it, then we could consider doing different things depending on the
> > message type. KERN_EMERG would disable preemption, whereas KERN_INFO may not be
> > so critical to require it.
> 
> That might be a bit difficult to implement with complete correctness
> given KERN_EMERG use and continuation lines.
> 

Or just have the current context determine what to do. If printk() was
called with preemption or interrupts disabled, it flushes the full
buffer before returning, otherwise it allows the writes to console be
preempted.

That would be great for -rt, as currently we don't even allow printk()
to write out if called from a interrupt disabled context, unless the
console it writes to is marked as preempt safe (serial console is
unfortunately not).

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/