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]
Date:	Wed, 22 Oct 2014 16:31:46 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Jiri Slaby <jslaby@...e.cz>,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH -next 00/27] tty locking changes

On Thu, 16 Oct 2014 16:24:58 -0400
Peter Hurley <peter@...leysoftware.com> wrote:

> Hi Greg,
> 
> This patch series has 3 major changes to how tty locking behaves:
> 1. the lock order of tty_lock() and tty->ldisc_sem is reversed;
>    this eliminates a bunch of lock drop/reacquire which, in turn,
>    eliminates tty state tracking that can no longer be observed.
>    This also allows the pty driver to wait for input processing to
>    complete while closing before setting TTY_OTHER_CLOSED (which
>    eliminates the ugliness of checking input twice in n_tty_read() and
>    n_tty_poll()).
> 2. the footprint of tty_mutex is reduced to only adding and removing
>    ttys and is no longer held to acquire the tty_lock() in tty_open();
>    this allows for multiple ttys to be opened concurrently, even if
>    one open stalls waiting for its tty_lock().
> 3. pty pair locking is reordered to master first, then slave, rather
>    than by address. This works because, while releasing the master pty,
>    the slave tty count needs to be changed, whereas, when releasing the
>    slave, the master pty does not need to be accessed.
>    This furthur eliminates more lock drop/reacquire.
> 
> The longer-term goals, which this series builds towards, is:
> 1. simplifying the tty open/close behavior
> 2. eliminating the ASYNC_CLOSING code without breaking existing userspace
> 3. eliminating returning -EIO from tty_open(). Not sure if this is possible yet.


Reviewed-by: Alan Cox <alan@...ux.intel.com>

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

Powered by blists - more mailing lists