[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwhFoU5Fp_VTMtVU7XFMZiNvy1J7n7YJsVBu+-k-EH0Nw@mail.gmail.com>
Date: Thu, 15 Dec 2011 09:08:32 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Ted Ts'o" <tytso@....edu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Greg KH <greg@...ah.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: printk() vs tty_io
On Thu, Dec 15, 2011 at 1:56 AM, Peter Zijlstra <peterz@...radead.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?
- 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.
Make code that isn't an oops or other very synchronous "have to
print out *now*" aim to use this "softer" printk.
Hmm?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists