tty locking again :)

tty locking again :)

[Benjamin Herrenschmidt]

Hi Alan !

(Asking you since I know you did some TTY locking work a while ago).

I noticed that there doesn't seem to be any kind of locking in
tty_(un)register_driver. It can very easily race with tty_open() doing a
get_tty_driver(). Shouldn't tty_(un)register_driver be changed to take
the tty_sem at least while manipulating the list ?

I noticed that while chasing a different bug (a driver bug actually),
but I don't see how we are protected here. And considering the race I
found in the driver, I tend to think we aren't protected at all

FYI. The hvc driver issue was basically that it was allowing struct
console->device (the kernel console callback to link to the tty driver)
to return the tty_driver pointer before it called tty_register_driver,
thus a racing tty_open() of the default console was blow up accessing
driver->ttys.

Ben.

Re: tty locking again :)

[Alan Cox]

On Gwe, 2005-11-04 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> I noticed that there doesn't seem to be any kind of locking in
> tty_(un)register_driver. It can very easily race with tty_open() doing a
> get_tty_driver(). Shouldn't tty_(un)register_driver be changed to take
> the tty_sem at least while manipulating the list ?

Its totally racy. Its on the todo list but I'm waiting for the buffering
changes to get into the Linus kernel and tested before doing the next
chunk of work on it (firstly fixing the rx/tx locking, then removing
TTY_DONT_FLIP which is a precursor to sanity for polled serial devices
and DMA)

> I noticed that while chasing a different bug (a driver bug actually),
> but I don't see how we are protected here. And considering the race I
> found in the driver, I tend to think we aren't protected at all

It all needs considerable work. Fixing the receive/transmit locking is
IMHO by far the most important however now the buffers are done.

Alan