Re: [PATCH 0/4 v6] Avoid softlockups in console_unlock()

[Andrew Morton]

On Thu, 22 Aug 2013 23:57:42 +0200 Jan Kara <jack@xxxxxxx> wrote:

> On Thu 22-08-13 12:49:13, Andrew Morton wrote:
> > Desperately seeking alternatives...
> > 
> > I suppose there's some reason why we can't just make those drivers shut
> > up?  If the messages are in the log buffer but aren't displayed,
> > they're still accessible after boot?
> > 
> > Or how about passing those messages over to a kernel thread, to be
> > printed out at a lower rate?  A linked list and schedule_work() would
> > suffice.
> 
>   Andrew, you seem really desperate ;-)

Years of hard experience have taught me: don't muck with printk.  It
needs to be robust, simple and to have minimum dependency on both the
calling environment and on correctly functioning kernel components. 
printk and NMI are the harshest environments we have to deal with.

> I don't really like modifying
> individual drivers, partitioning code, or SCSI core to be less verbose -
> IMHO that's fighting with windmills and it's not like any of those parts is
> excessively verbose. Every part prints its bits and it accumulates. I
> cannot really imagine this would work long term.
> 
> Handing over printing to someone else is exactly what I'm doing

No you aren't - you're mucking with printk!

What I'm proposing is to put a front-end *before* printk.  Thus leaving
printk unmucked with.

But it was just a suggestion.  Maybe there are other ways.  I'm
inviting you to suggest ways of fixing this obscure corner case
without mucking with everyone's printk.

--
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/