linux-kernel - Re: patch "TTY: remove tty

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, 24 Aug 2011 16:53:57 +0100
From:	Alan Cox <alan@...ux.intel.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Jiri Slaby <jslaby@...e.cz>, gregkh@...e.de,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: patch "TTY: remove tty_locked" added to tty tree

> It's not clear to me what state->mutex protects in the serial_core,
> but it has been around forever (used to be called state->sem) and is
> held in all uart functions, which is at least consistent. IIRC what
> Alan's plan for this was, uart_close should eventually get changed to
> use tty_port_close_start or even tty_port_close. Maybe the time for
> that has come now, lacking better alternatives?

That was certainly the plan.

> A lot of other drivers call tty_port_close_start() before taking
> port->mutex.

You don't need the port->mutex for tty_port_close_start() if I got it
right, the reason for taking it across the whole of tty_port_close is
so we would end up with a simple API which could be explained as

"open, close and hangup manage locking internally, you will never get
 the events overlapping in any callback. Initialize and shutdown
 callbacks will only be called once with each initialize of the first
 open matching a shutdown of the final close"

It has no meaningful performance impact so it seemed silly not to
provide a somewhat more accident-proof API.
--
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/