From: Peter Hurley <peter@hurleysoftware.com>
To: David Laight <David.Laight@ACULAB.COM>, Arnd Bergmann <arnd@arndb.de>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Karsten Keil <isdn@linux-pingi.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()
Date: Tue, 17 Jun 2014 07:32:15 -0400 [thread overview]
Message-ID: <53A0273F.70400@hurleysoftware.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1725DAF6@AcuExch.aculab.com>
On 06/17/2014 07:03 AM, David Laight wrote:
> From: Peter Hurley
> ...
>>> 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).
>
> What happens if another process tries to do a non-blocking open
> while you are sleeping in close waiting for output to drain?
>
> Hopefully this returns before that data has drained.
Good point.
tty_open() should be trylocking both mutexes anyway in O_NONBLOCK.
Regards,
Peter Hurley
WARNING: multiple messages have this Message-ID (diff)
From: Peter Hurley <peter@hurleysoftware.com>
To: David Laight <David.Laight@ACULAB.COM>, Arnd Bergmann <arnd@arndb.de>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Karsten Keil <isdn@linux-pingi.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()
Date: Tue, 17 Jun 2014 07:32:15 -0400 [thread overview]
Message-ID: <53A0273F.70400@hurleysoftware.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1725DAF6@AcuExch.aculab.com>
On 06/17/2014 07:03 AM, David Laight wrote:
> From: Peter Hurley
> ...
>>> 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).
>
> What happens if another process tries to do a non-blocking open
> while you are sleeping in close waiting for output to drain?
>
> Hopefully this returns before that data has drained.
Good point.
tty_open() should be trylocking both mutexes anyway in O_NONBLOCK.
Regards,
Peter Hurley
next prev parent reply other threads:[~2014-06-17 11:32 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 13:16 [PATCH tty-next 00/22] tty/serial fixes for 3.17 Peter Hurley
2014-06-16 13:16 ` [PATCH tty-next 01/22] tty: Document locking for tty driver methods Peter Hurley
2014-06-16 13:16 ` [PATCH tty-next 02/22] tty: Document locking for tty_port_close{,start,end}() Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 03/22] tty: Document locking for tty_port_open() Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 04/22] tty: Document locking for tty_port_block_til_ready() Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 05/22] tty: Document locking for tty_port_hangup() Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 06/22] tty: Move tty->closing from port lock critical section Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 07/22] tty: ipwireless: Remove tty->closing abort from ipw_open() Peter Hurley
2014-06-16 14:09 ` David Sterba
2014-06-16 13:17 ` [PATCH tty-next 08/22] serial: Use UPF_* constants with struct uart_port flags Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 09/22] tty: Remove tty_hung_up_p() tests from tty drivers' open() Peter Hurley
2014-06-16 13:52 ` Jesper Nilsson
2014-06-16 13:17 ` [PATCH tty-next 10/22] char: synclink: Remove WARN_ON for bad port count Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 11/22] tty: Call hangup method in modern style Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 12/22] tty: serial: Fix termios/port flags mismatch Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 13/22] serial: blackfin: Fix CTS flow control Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close() Peter Hurley
2014-06-16 13:17 ` Peter Hurley
2014-06-17 8:00 ` Arnd Bergmann
2014-06-17 8:00 ` Arnd Bergmann
2014-06-17 8:18 ` David Laight
2014-06-17 8:18 ` David Laight
2014-06-17 8:18 ` David Laight
2014-06-17 10:57 ` Peter Hurley
2014-06-17 10:57 ` Peter Hurley
2014-06-17 11:03 ` David Laight
2014-06-17 11:03 ` David Laight
2014-06-17 11:03 ` David Laight
2014-06-17 11:31 ` Arnd Bergmann
2014-06-17 11:31 ` Arnd Bergmann
2014-06-17 11:54 ` One Thousand Gnomes
2014-06-17 11:54 ` One Thousand Gnomes
2014-06-17 11:32 ` Peter Hurley [this message]
2014-06-17 11:32 ` Peter Hurley
2014-07-09 13:57 ` Peter Hurley
2014-07-09 13:57 ` Peter Hurley
2014-10-08 3:56 ` Peter Hurley
2014-10-10 8:58 ` One Thousand Gnomes
2014-10-10 8:58 ` One Thousand Gnomes
2014-07-10 23:09 ` Greg Kroah-Hartman
2014-07-10 23:09 ` Greg Kroah-Hartman
2014-07-11 15:03 ` Peter Hurley
2014-07-11 15:03 ` Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 15/22] isdn: tty: Use private flag for ASYNC_CLOSING Peter Hurley
2014-06-16 15:37 ` David Laight
2014-06-16 21:01 ` Peter Hurley
2014-06-17 11:58 ` One Thousand Gnomes
2014-06-16 13:17 ` [PATCH tty-next 16/22] tty: mxser: Use tty->closing " Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 17/22] tty: Remove ASYNC_CLOSING Peter Hurley
2014-06-16 13:52 ` Jesper Nilsson
2014-06-16 13:17 ` [PATCH tty-next 18/22] tty: Move tty hung up check from port->lock critical section Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 19/22] serial: Style fix Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 20/22] serial: Refactor uart_flush_buffer() from uart_close() Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 21/22] serial: core: Remove superfluous ldisc flush " Peter Hurley
2014-07-11 16:15 ` Peter Hurley
2014-06-16 13:17 ` [PATCH tty-next 22/22] serial: Fix locking for uart driver set_termios() method Peter Hurley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53A0273F.70400@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=David.Laight@ACULAB.COM \
--cc=arnd@arndb.de \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=isdn@linux-pingi.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.