Message-ID: <563BBC37.9090708@hurleysoftware.com>
Date:	Thu, 5 Nov 2015 15:29:43 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Pavel Labath <labath@...gle.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: ptrace and pseudoterminals

On 11/05/2015 01:35 PM, Pavel Labath wrote:
> On 5 November 2015 at 05:25, Peter Hurley <peter@...leysoftware.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists