[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1323855488.28489.16.camel@twins>
Date: Wed, 14 Dec 2011 10:38:08 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Greg KH <greg@...ah.com>, Theodore Ts'o <tytso@....edu>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
linux-kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: printk() vs tty_io
On Tue, 2011-12-13 at 15:52 -0800, Linus Torvalds wrote:
> On Tue, Dec 13, 2011 at 11:33 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > I've been poking at reducing the constraints on printk(), like make it
> > work under rq->lock etc..
>
> You aren't supposed register a console that wakes things up. But the
> only console that honors that afaik is the traditional vt console.
> *Maybe* the network console, I didn't check.
>
> I *assume* you only get this lockdep warning if you have a serial console?
I only ever use serial, I'll try and have a go at reproducing any of
this on a machine that actually has a screen attached.
Anyway, would it make any sense to start enforcing this 'rule'? Can we
reasonably make the serial stuff not wake things? Let alone the
fbdev/ksm consoles that seem popular these days.
Thing is, if everybody and their dog are using ksm, and we cannot make
ksm console wake-free, there's a very limited point to my endeavor to
make printk() work under rq->lock etc..
--
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