On 06/17/2014 04:00 AM, Arnd Bergmann wrote:
On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fifo).
However, dropping the tty lock is a hold-over from when the tty
lock was system-wide; ie., one lock for all ttys.
Since commit 89c8d91e31f267703e365593f6bfebb9f6d2ad01,
'tty: localise the lock', dropping the tty lock has not been necessary.
CC: Karsten Keil <isdn@xxxxxxxxxxxxxx>
CC: linuxppc-dev@xxxxxxxxxxxxxxxx
Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs the lock to complete the function that
sends the pending data. I don't think we do still do that any more,
but it doesn't seem related to the tty lock being system-wide or not.
The tty lock is not used in the i/o path; it's purpose is to
mutually exclude state changes in open(), close() and hangup().
The commit that added this [1] comments that _other_ ttys may wait
for this tty to complete, and comments in the code note that this
function should be removed when the system-wide tty mutex was removed
(which happened with the commit noted in the changelog).
Regards,
Peter Hurley
[1]
commit a57a7bf3fc7eff00f07eb9c805774d911a3f2472
Author: Jiri Slaby <jslaby@xxxxxxx>
Date: Thu Aug 25 15:12:06 2011 +0200
TTY: define tty_wait_until_sent_from_close
We need this helper to fix system stalls. The issue is that the rest
of the system TTYs wait for us to finish waiting. This wasn't an issue
with BKL. BKL used to unlock implicitly.
This is based on the Arnd suggestion.
Signed-off-by: Jiri Slaby <jslaby@xxxxxxx>
Acked-by: Arnd Bergmann <arnd@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
