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, 10 Sep 2014 17:24:10 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Jiri Slaby <jslaby@...e.cz>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal

On Wed, Sep 10, 2014 at 08:11:14PM -0400, Peter Hurley wrote:
> On 09/10/2014 08:03 PM, Greg Kroah-Hartman wrote:
> > On Wed, Sep 10, 2014 at 05:28:19PM -0400, Peter Hurley wrote:
> >> This patch changes user-space behavior (for the better) but I'm not sure
> >> that it's consequence-free. Also, it might not be enough to unwedge the
> >> terminal if the driver got its own flow control state mangled.
> >>
> >> Thoughts?
> >>
> >> --- >% ---
> >> Subject: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal
> >>
> >> If terminal flow has been stopped, the terminal can be unwedged
> >> by:
> >> 	tcflow(fd, TCOOFF);
> >> 	tcflow(fd, TCOON);
> >> This works because tcflow(TCOOFF) ensures that ->flow_stopped is set,
> >> which allows tcflow(TCOON) to override the terminal flow state in
> >> __start_tty().
> >>
> >> Instead, allow unwedging with only:
> >>         tcflow(fd, TCOON);
> >> by disregarding the existing ->flow_stopped state.
> > 
> > I don't see the benifit here, what are you trying to solve?  Sending one
> > extra tcflow command?
> 
> It's not common knowledge (and its certainly counterintuitive) that
> turning off output when output is already turned off (ie., tcflow(TCOOFF))
> is the required trickery to unwedge a terminal.
> 
> Unwedging directly seems the straightforward approach.

What's the odds we break POSIX with this type of change?

I'm all for working around broken hardware in the kernel, but this seems
like a very old issue, if it's even one at all, that we would be
changing for no one who has reported it (that I know of...)

In other words, I'm really leary of changing userspace functionality
without having a real need/reason to.

thanks,

greg k-h
--
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