linux-kernel - Re: [PATCH 07/16] TTY: quatech2, remove unneeded is

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: <20130313142705.E8E8880208@viridian.itc.virginia.edu>
Date:	Wed, 13 Mar 2013 10:27:05 -0400
From:	wfp5p@...idian.itc.virginia.edu (Bill Pemberton)
To:	jslaby@...e.cz (Jiri Slaby)
Cc:	gregkh@...uxfoundation.org, peter@...leysoftware.com,
	jirislaby@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/16] TTY: quatech2, remove unneeded is_open

Jiri Slaby writes:
> 
> On 03/13/2013 02:46 PM, Bill Pemberton wrote:
> > Jiri Slaby writes:
> >>
> >> tty->ops->break_ctl cannot be called outside the gap between open and
> >> close. So there is no need to check whether the port is open in
> >> break_ctl in quatech2. Remove the check and also that member
> >> completely.
> >>
> > 
> > We can't get rid of is_open.  The devices use 1 read urb for all ports
> > and will send various things about ports that haven't actually been
> > opened.  So the driver needs to know if a port has actually been
> > opened or not.  In fact, I was about to send a patch that fixes a
> > warning caused by commit 2e124b4a390ca85325fae75764bef92f0547fa25
> > causing the driver to try to write to ttys that weren't actually
> > opened.
> 
> As long as tty_port exists for the port, calling tty buffer functions is
> OK. The warning you mention is now bogus and there is a patch flying
> around to disable that at the moment.
> 

Ah, ok, I assumed the warning was telling me the driver was doing
something stupid by calling tty_flip_buffer_push() on a port that
wasn't opened (which did sound like a stupid thing to do to me).  If
that's actually harmless, then yes, the is_open stuff can be dropped
and my recent patch to check is_open before calling
tty_flip_buffer_push() can be ignored.


> It is also that is_open was completely racy, right?
> 

Does it simply need a lock around it or is there something else I'm
missing?  In any event, if it can go, that's great -- it's only used
for the above "don't call tty_flip_buffer_push() on an unopened port"
logic.

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