linux-kernel - Re: [PATCH v3 3/6] TTY: fix DTR being raised on hang up

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: <1363348674.3194.167.camel@thor.lan>
Date:	Fri, 15 Mar 2013 07:57:54 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Johan Hovold <jhovold@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-usb@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/6] TTY: fix DTR being raised on hang up

On Fri, 2013-03-15 at 12:30 +0100, Johan Hovold wrote:
> On Fri, Mar 15, 2013 at 07:03:08AM -0400, Peter Hurley wrote:
> > On Fri, 2013-03-15 at 10:24 +0100, Johan Hovold wrote:
> > > On Wed, Mar 13, 2013 at 03:43:43PM -0400, Peter Hurley wrote:
> > > > On Thu, 2013-03-07 at 15:55 +0100, Johan Hovold wrote:
> > > > > Make sure to check ASYNC_INITIALISED before raising DTR when waking up
> > > > > from blocked open in tty_port_block_til_ready.
> > > > > 
> > > > > Currently DTR could get raised at hang up as a blocked process would
> > > > > raise DTR unconditionally before checking for hang up and returning.
> > > > > 
> > > > > Signed-off-by: Johan Hovold <jhovold@...il.com>
> > > > > ---
> > > > >  drivers/tty/tty_port.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
> > > > > index 3de5918..52f1066 100644
> > > > > --- a/drivers/tty/tty_port.c
> > > > > +++ b/drivers/tty/tty_port.c
> > > > > @@ -355,7 +355,7 @@ int tty_port_block_til_ready(struct tty_port *port,
> > > > >  
> > > > >  	while (1) {
> > > > >  		/* Indicate we are open */
> > > > > -		if (tty->termios.c_cflag & CBAUD)
> > > > > +		if (C_BAUD(tty) && test_bit(ASYNCB_INITIALIZED, &port->flags))
> > > > >  			tty_port_raise_dtr_rts(port);
> > > > >  
> > > > >  		prepare_to_wait(&port->open_wait, &wait, TASK_INTERRUPTIBLE);
> > > > 
> > > > This is ok, but there are 6 other *_block_til_ready() functions:
> >      ^^^^^^
> > Comment on patch
> 
> I saw that, but just wanted to stress that those comments shouldn't
> block the series.

I completely agree. In fact, I should have said as much in the initial
review. Sorry.

> > > Yes, but that's not really a comment on this patch, is it?
> > > 
> > > The purpose of this series is to fix the tty-port implementation, and
> > > I've only touched individual drivers when I had to in order not to break
> > > anything due to changed assumptions.
> > > 
> > > There's a ton of buggy and odd behaviour to be found once you start
> > > turning the stones. Drivers like the ones below really ought to be
> > > using tty ports and it's helpers.
> > 
> > Sure, I understand.
> > 
> > OTOH, tty_port and these drivers stem from the same ancestor and it's
> > partly because of localized bug fixes like these that the drivers have
> > buggy and odd behavior (because tty_port gets fixed and these do not).
> 
> Arguably, fixing the core isn't really a localised bug fix. Some of
> those drivers you mentioned have custom open, close, hangup which are
> quite different from the tty port implementation, and surely would have
> a lot to gain from being ported to tty ports if someone could find the
> time to do so.

I think the reluctance to do a full port is partly due to lack of
testable hardware.

> > As you can verify from the changelogs of these drivers, it's traditional
> > to continue to maintain the common aspects, despite the desire to
> > abandon them.
> 
> Most entries I see have to do with changed interfaces.
> 
> > That said, I'm not the maintainer so feel free to disagree with my
> > point-of-view.
> 
> You do have a point, and I will try to find the time for a follow-up
> series fixing at least a few of those five-or-so custom block_til_ready
> you pointed to.

Thanks.

Regards,
Peter Hurley

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