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
| ||
|
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/
Powered by blists - more mailing lists