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

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

The specific case of waiting for queues to empty could be a slow one and
probably wants to addressed nicely. The other causes like memory
allocator waits are probably actually better the new way. What exactly is
an application supposed to do when it gets a -EIO on open, how does it
decide when to try again, when does it retry, how many aps get it right ?

In fact I don't think its unreasonable to treat an open without O_NDELAY
that blocks on a close flushing output from buffers as correct - unless
there is some specific POSIX reason why we cannot.

I'd venture we'd effective fix/hide/cover over a huge range of extremely
obscure and near untestable app failure cases/bugs by doing this.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ