Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755368AbbKEU3s (ORCPT ); Thu, 5 Nov 2015 15:29:48 -0500 Received: from mail-ig0-f169.google.com ([209.85.213.169]:33576 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbbKEU3r (ORCPT ); Thu, 5 Nov 2015 15:29:47 -0500 Subject: Re: ptrace and pseudoterminals To: Pavel Labath References: <563A3A32.2030102@hurleysoftware.com> <20151104194314.GA21386@redhat.com> <563B58C1.8070201@hurleysoftware.com> Cc: Oleg Nesterov , linux-kernel@vger.kernel.org From: Peter Hurley Message-ID: <563BBC37.9090708@hurleysoftware.com> Date: Thu, 5 Nov 2015 15:29:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 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: 3228 Lines: 80 On 11/05/2015 01:35 PM, Pavel Labath wrote: > On 5 November 2015 at 05:25, Peter Hurley wrote: >> On 11/04/2015 02:43 PM, Oleg Nesterov wrote: >>> Oh, I don't think "Automagically if ptrace" makes any sense... What makes >>> ptrace special? Afaics nothing. >>> >>> We can modify this test-case to use signals/futexes/whatever to let the >>> the parent know that the child has already done write(writefd), and it can >>> "fail" the same way. >> >> True. >> >> Also, new patches in mainline head make this _much_ less likely >> by scheduling the input processing kworker on the unbound wq (which means >> the kworker can start immediately on another cpu rather than pinned to >> the cpu performing the slave write). >> >> After thinking more about this, this use-case seems trivially solvable >> by re-select()ing with a timeout prior to reporting mismatch output >> failure. >> >> Regards, >> Peter Hurley >> > > Thank you for the replies. > > I agree that this can be worked around on our side, but I wanted to > confirm whether this is expected behavior or a bug. Judging from your > answers, it seems this is working as intended. > > That said, it seems to me that this could be a generally useful > feature. For the test suite, I can insert a sleep (even a large one, > to be sure), but this seems like a sub-optimal solution for general > debugger operation. E.g., when we want to display all tracee output(*) > before we print out the debugger prompt, we don't know if the tracee > has written anything, and we would need to sleep always, just in case > it has done that. My comment suggesting re-select()ing was aimed at the test suite only. For the debugger, I would always mixin new output from the target regardless of when it arrived. But feel free to ignore my unsolicited design advice :) > This is especially tricky for remote debugging, as > the current gdb-remote protocol does not allow sending stdio after the > stop notification. Hmm, I could swear I've seen gdb scrolling away with new output while stopped. > So, I actually quite like the fsync() idea, but I > don't know if this is something that would be generally accepted (?). Let me think more on this; maybe I can come up with a way to trip it within an existing method. > (*) To avoid mixing output we don't have the tracee share the same > terminal with the debugger, but we create a new one, and do the > forwarding ourselves. Aside from avoiding output mixing, this > facilitates IDE integration, remote debugging, etc. > > > A side question: When I replace the pty with a pipe, the data seems to > be delivered immediately. Is this something that is guaranteed, or > this happens to work only accidentally and could change in the future > (e.g. by moving the pipe processing to a kworker process or whatever)? I would think the existing pipe behavior is more or less guaranteed, since pipes are commonly used for process synchronization. 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/