[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080507191926.GA19802@flint.arm.linux.org.uk>
Date: Wed, 7 May 2008 20:19:26 +0100
From: Russell King <rmk+lkml@....linux.org.uk>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] NULL pointer dereference in uart_write_room().
On Mon, May 05, 2008 at 11:30:55AM +0100, Alan Cox wrote:
> > (5) uart_remove_one_port() is called by serial8250_register_port()
> > since ttyS0 is already in use but it is requested to be once removed.
>
> That means 8250_pnp is taking over and then trying to delete the console,
> so its breakage in the serial layer glue. Perhaps Russell has some ideas
> as its hard to tell what he intended to happen originally.
Looking at the original report, yes, it is (and will) try to delete the
console.
However, it's doing the best it can to tell the tty layer "oi, this is
port going away, don't do anything more with it" by hanging it up.
The real question is: why, after we try to hang up a specific port, is
the tty layer continuing to use the port... and the answer is that the
tty layer exempts the console from the usual hangup processing.
IOW, you can not hang up the console port or indeed ever safely unregister
it.
Other solutions? Well, we could modify it in place but that gets awfully
icky and racy with... the console, so we wouldn't actually be solving
anything.
The only other solution I can think of is to basically deny any change
to the console port, so it never disappears, and therefore never becomes
owned by PNP, PCI or whatever. Which also means that it'll probably
mess up power management of it. I guess broken console PM is more
preferable than oopsing peoples machines.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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