linux-kernel - Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'

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:	Mon, 4 May 2015 14:24:13 +0200 (CEST)
From:	Michael Matz <matz@...e.de>
To:	Peter Hurley <peter@...leysoftware.com>
cc:	NeilBrown <neilb@...e.de>,
	Nic Percival <Nic.Percival@...rofocus.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
 'no' when it should say 'yes'

Hi,

On Fri, 1 May 2015, Peter Hurley wrote:

> I don't think this a real bug, in the sense that pty i/o is not 
> synchronous, in the same way that tty i/o is not synchronous.

Here's what I wrote internally about my speculations about this being a 
bug or not:

> > I also never hit it with pipes (remove the USEPTY define), also not on 
> > sle12, so it must be some change specific to the pty implementation.
> > 
> > Now, all of this is of course unspecified.  There are two asynchronous 
> > processes involved, and a buffered tube between them.  Just because 
> > one process filled one end of the tube (the breakpoint was hit) 
> > doesn't mean the contents have to appear at that instant at the other 
> > end.  So the change in behaviour in sle12 is not a genuine bug.  It 
> > _might_ be an unintented change, though, that's why kernel people 
> > should comment on this.  If there are no terribly good reasons for 
> > this change I'd consider it a quality-of-implementation regression in 
> > sle12.

So, I'd accept this being declared a non-bug, but it is certainly a change 
in behaviour that's visible for our debugger team.

> However, that said, if this is a regression (regression as in "it broke 
> something that used to work", not regression as in "this new thing I'm 
> writing doesn't behave the way I want it to" :) )
> 
> Help me understand the use-case here: are you using pty i/o to debug the 
> debugger?

Nic is working on the Cobol debugger, but I think this pty i/o is rather a 
part of the normal interaction between a debugged Cobol process and the 
debugger; that's just a theory, Nic is authorative here.  But this change 
in behaviour _did_ result in real testsuite regressions, so it's not 
something that he wanted to write from scratch.

(FWIW: I do think it's a better QoI factor if something returns data from 
a tube if we can know via side channels (break points) that something must 
have been written locally to the other end of the tube, if that can be 
ensured without too much other work)


Ciao,
Michael.
--
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/