Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162271AbbKESfi (ORCPT ); Thu, 5 Nov 2015 13:35:38 -0500 Received: from mail-lf0-f51.google.com ([209.85.215.51]:34914 "EHLO mail-lf0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756604AbbKESfg (ORCPT ); Thu, 5 Nov 2015 13:35:36 -0500 MIME-Version: 1.0 In-Reply-To: <563B58C1.8070201@hurleysoftware.com> References: <563A3A32.2030102@hurleysoftware.com> <20151104194314.GA21386@redhat.com> <563B58C1.8070201@hurleysoftware.com> From: Pavel Labath Date: Thu, 5 Nov 2015 10:35:15 -0800 Message-ID: Subject: Re: ptrace and pseudoterminals To: Peter Hurley Cc: Oleg Nesterov , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2557 Lines: 59 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. This is especially tricky for remote debugging, as the current gdb-remote protocol does not allow sending stdio after the stop notification. So, I actually quite like the fsync() idea, but I don't know if this is something that would be generally accepted (?). (*) 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)? regards, pl -- 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/