Re: [GIT PATCH] TTY patches for 2.6.36

[Arnd Bergmann]

On Monday 09 August 2010, Andy Whitcroft wrote:
> With the new locking the BTM is held in place of the BKL, which
> effectivly means throughout open and close processing, which
> effectively means all TTY open/closes are serialised throughout
> regardless of the length of the shutdown processing.  The EIO appears
> to be no longer returnable.
> 
> Is this change in semantics expected?  If not, it is likely something
> which could be addressed separately after merging, as long as we are
> aware.

I audited (or tried to) all code that is able to sleep while holding the
BTM. In the cases that looked like they might sleep long, I added explicit
tty_unlock()/tty_lock() pairs around the sleeping code.

Code that potentially sleeps but should not do so for an indefinite
time (e.g. kmalloc(GFP_KERNEL)), I did not do this and still hold the BKL.

This means the code shifted to holding the BTM more often than it used
to hold the BKL, but for cases where we wait on user or hardware interaction,
it should still behave as it used to. If you found a place where this
is not true, that is probably an oversight and we should add explicit
tty_unlock() statements around it.

The problem is that we cannot easily give up the BTM while already holding
tty_port->mutex, tty_port->buf_mutex, console_semaphore, tty->termios_mutex
or tty->atomic_write_lock, which would give an AB-BA deadlock without
the autorelease semantics of the BKL. Similarly, any wait_event or
flush_work_queue potentially has the same problem (besides the fact that
it can self-deadlock what it waits for tried to take the BTM). Auditing
all these was the bulk of the work for the conversion.

I did not specifically audit for the case where tty_open() returns -EIO,
but I'd hope that it would be covered by the method I used for the
conversion.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/