linux-kernel - Re: linux-next: build failure after merge of the tty tree

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, 20 Mar 2013 10:42:32 -0400
From:	wfp5p@...idian.itc.virginia.edu (Bill Pemberton)
To:	jslaby@...e.cz (Jiri Slaby)
Cc:	sfr@...b.auug.org.au (Stephen Rothwell), greg@...ah.com (Greg KH),
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the tty tree

Jiri Slaby writes:
> 
> On 03/20/2013 01:51 PM, Bill Pemberton wrote:
> > Jiri Slaby writes:
> >>
> >>> drivers/usb/serial/quatech2.c: In function 'qt2_process_read_urb': 
> >>> drivers/usb/serial/quatech2.c:661:18: error: 'struct
> >>> qt2_port_private' has no member named 'is_open' 
> >>> drivers/usb/serial/quatech2.c:705:15: error: 'struct
> >>> qt2_port_private' has no member named 'is_open'
> >>>
> >>> Caused by commit e4408ce3c23f ("TTY: quatech2, remove unneeded 
> >>> is_open").  grep is your friend (or searching while editting the
> >>> file).
> >>
> >> I think this is caused by another commit. Bill added a check for
> >> is_open meanwhile I removed that member completely. Bill, could you
> >> fix that up, please?
> >>
> > 
> > Is it legal to call tty_flip_buffer_push() without an open tty?  If
> > so, I can get rid of the is_open logic completely.  Otherwise, I need
> > to either keep is_open or otherwise check for a valid tty before
> > calling tty_flip_buffer_push().
> 
> Yeah, it is legal to call that, as long as you have a valid tty_port.
> Now, the data are queued and later flushed. The plan is to throw the
> data directly on ingress in a way the drivers don't need to care.
> 

Ok, for the unopened ports there *should* never be any actual data to
push so the push is really doing nothing anyhow in these cases.  It's
coming from the device sending an initial change port command.

Anyhow, so my patch adding more is_open logic can be dropped and then
yours will apply fine.  What's the best way for me to handle this?
Send a revert for my patch so yours will apply or send an updated
version of your patch that removes my additions?


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