linux-kernel - Re: [GIT PATCH] TTY patches for 2.6.36

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: <AANLkTinaQz22DAzrcvYREWAe9AFv8enC88Gu_9o_Ghg-@mail.gmail.com>
Date:	Mon, 9 Aug 2010 17:06:03 +0100
From:	Andy Whitcroft <apw@...onical.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Andy Whitcroft <apw@...onical.com>
Subject: Re: [GIT PATCH] TTY patches for 2.6.36

On Fri, Aug 6, 2010 at 9:22 PM, Greg KH <gregkh@...e.de> wrote:
> On Fri, Aug 06, 2010 at 09:58:45PM +0200, Arnd Bergmann wrote:
>> On Friday 06 August 2010 21:38:36 Linus Torvalds wrote:
>> > I also don't want the BKL to show up in grep, even if the config
>> > option for it were to be impossible to enable. If we've gotten far
>> > enough that we can get rid of the BKL in the tty layer, we really
>> > should get rid of it. Not leave it in some zombie limbo state.
>>
>> Ok, I've sent the replacement patch that does this, and I'm much
>> happier with the outcome.
>>
>> If you apply this version, the only stronghold left for the BKL
>> will be fs/lockd, everything else that's left is either simple
>> to fix or highly obscure.
>
> Ok, I got that one now, and am building the tree to test here before
> sending to Linus.

I have been looking at the proposed change to the TTY locking here.
The conversion of the BKL into a real non-preemptable lock for the TTY
layer has had an interesting semantic change on racing open/closes on
the same TTY.  Prior to the changes we would:

 - grab the BLK and tty_mutex
 - mark the device TTY_CLOSING
 - drop the tty_mutex
 - call device shutdown
 - prevent the device from being found
 - drop the BKL

The use of the BLK to cover the device shutdown has an interesting
effect.  Where the shutdown processing is simple the lock is
maintained and the whole processing is atomic with respect to racing
opens and closes, such that an open would never see TTY_CLOSING.  For
any shutdown processing which resulted in a sleep then the BKL would
be implicitly dropped and reaquired allowing any racing opens to
continue and triggering an open failure errno=EIO, something POSIX at
least hints at as reasonable.  As shutdown can include hardware
interactions this seems like appropriate behaviour, and cirtinly the
git log documents this as expected and desirable semantics.

With the new locking the BTM is held in place of the BKL, which
effectivly means throughout open and close processing, which
effectively means _all_ TTY open/closes are serialised throughout
regardless of the length of the shutdown processing.  The EIO appears
to be no longer returnable.

Is this change in semantics expected?  If not, it is likely something
which could be addressed separately after merging, as long as we are
aware.

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