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, 04 May 2015 12:32:04 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Michael Matz <matz@...e.de>
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'

On 05/04/2015 08:24 AM, Michael Matz wrote:
> 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.

I'd like to understand why the debugger cares about when pty i/o shows up
and why there is a testsuite to check for that.

Does the debuggee know about the debugger, or is the pty i/o just stdout/stderr?

This doesn't seem stable in the face of multiple threads of execution in
the debuggee (or grandchild processes); IOW, pty slave writes from the
debuggee may continue from other non-TRACEME threads. Presumably that i/o
isn't being read either.

> (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)

Well, if the debugger simply continues to monitor the pty master, the i/o
will arrive.

I think it would be a shame if ptrace() usage forced a whole class of
i/o to be synchronous.

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/