linux-kernel - Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53A01F02.7000202@hurleysoftware.com>
Date:	Tue, 17 Jun 2014 06:57:06 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Arnd Bergmann <arnd@...db.de>, linuxppc-dev@...ts.ozlabs.org
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Karsten Keil <isdn@...ux-pingi.de>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()

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@...ux-pingi.de>
>> CC: linuxppc-dev@...ts.ozlabs.org
>> Signed-off-by: Peter Hurley <peter@...leysoftware.com>
>
> 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@...e.cz>
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@...e.cz>
     Acked-by: Arnd Bergmann <arnd@...db.de>
     Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

--
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/