Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbbEDQcP (ORCPT ); Mon, 4 May 2015 12:32:15 -0400 Received: from mail-qk0-f174.google.com ([209.85.220.174]:36695 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887AbbEDQcI (ORCPT ); Mon, 4 May 2015 12:32:08 -0400 Message-ID: <55479F04.8010009@hurleysoftware.com> Date: Mon, 04 May 2015 12:32:04 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Matz CC: NeilBrown , Nic Percival , Greg Kroah-Hartman , Jiri Slaby , linux-kernel@vger.kernel.org Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes' References: <20150501162040.05c0cb42@notabene.brown> <5543964C.9030606@hurleysoftware.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3032 Lines: 69 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/