All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>, "Ted Ts'o" <tytso@mit.edu>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg KH <greg@kroah.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: printk() vs tty_io
Date: Thu, 15 Dec 2011 19:07:25 +0100	[thread overview]
Message-ID: <20111215180725.GA30567@elte.hu> (raw)
In-Reply-To: <CA+55aFwhFoU5Fp_VTMtVU7XFMZiNvy1J7n7YJsVBu+-k-EH0Nw@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Dec 15, 2011 at 1:56 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > We probably could, I can have a closer look, but the main question is,
> > are we going to commit to no wakeups from console implementations? That
> > would mean removing the USB serial console support and other such stuff.
> 
> I guess we can't.
> 
> So new approach:
> 
>  - screw it. the rq lock is just too central, you cannot call 
> printk from under it. And if you have an oops under it, you're 
> screwed.
> 
>    Peter, why do you want to try to work from under the rq 
>    lock?

Well, no real strong reason: we had that nasty xtime_lock 
related lockup in printk() (which was arguably much worse than 
the rq lock dependency - and it got fixed), and everyone assumed 
that somehow we could just remove the rq lock dependency from 
printk() as well.

It appears we can't - and that's OK.

Was an intellectual excercise which didnt work out.

>  - Make a special "debug printk" that is not synchronous. Just 
> make it buffer things, and have it actually print out from a 
> worker thread or whatever. This one *only* takes the lock for 
> that buffer itself, and works everywhere. We could probably 
> even do tricks to make it NMI-safe.

We kind of already have such a thing: trace_printk() - which 
works from the weirdest of atomic contexts as well.

IIRC Peter uses trace_printk() to develop the scheduler all the 
time.

What we could perhaps do is a sort of 'shut up regular printk 
and feed all printks into the trace buffers' kind of debug 
switch.

>    Make code that isn't an oops or other very synchronous 
> "have to print out *now*" aim to use this "softer" printk.

For early and nast oopses we have a very primitive printk: 
earlyprintk=keep which can just act as a full printk 
replacement. I use earlyprintk=keep while regular printk is 
disabled (there's no console).

[ earlyprintk can be used to debug everything except printk() 
  lockups, obviously. ]

Thanks,

	Ingo

  reply	other threads:[~2011-12-15 18:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-13 19:33 printk() vs tty_io Peter Zijlstra
2011-12-13 23:52 ` Linus Torvalds
2011-12-14  9:38   ` Peter Zijlstra
2011-12-14 10:43   ` Alan Cox
2011-12-14 10:56     ` Peter Zijlstra
2011-12-14 14:05       ` Ted Ts'o
2011-12-14 14:23         ` Peter Zijlstra
2011-12-14 15:54           ` Linus Torvalds
2011-12-15  9:56             ` Peter Zijlstra
2011-12-15 10:32               ` Alan Cox
2011-12-15 10:55                 ` Peter Zijlstra
2011-12-15 17:08               ` Linus Torvalds
2011-12-15 18:07                 ` Ingo Molnar [this message]
2011-12-15 21:22                 ` Alan Cox
2011-12-16 13:25                 ` Peter Zijlstra
2011-12-15 19:02               ` Greg KH
2011-12-14  6:59 ` Ingo Molnar
2011-12-14  9:40   ` [PATCH] arch, early_printk: Consolidate early_printk() implementations Peter Zijlstra
2011-12-14  9:41   ` [PATCH] lockdep: Enable earlyprintk output Peter Zijlstra
2011-12-14  9:43   ` printk() vs tty_io Peter Zijlstra
2011-12-14  9:46     ` Ingo Molnar
2011-12-21 12:03 ` Stijn Devriendt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111215180725.GA30567@elte.hu \
    --to=mingo@elte.hu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.