Date: Wed, 4 Nov 2015 20:43:14 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Pavel Labath <labath@google.com>, linux-kernel@vger.kernel.org
Subject: Re: ptrace and pseudoterminals
Message-ID: <20151104194314.GA21386@redhat.com>
References: <CAJt8pk_DJbjHFvGiyeg1w62trZjgeGm=2Nrx7iHORCRtXHAyow@mail.gmail.com> <563A3A32.2030102@hurleysoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <563A3A32.2030102@hurleysoftware.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2738
Lines: 66

On 11/04, Peter Hurley wrote:
>
> Hi Pavel,
>
> On 11/03/2015 06:16 PM, Pavel Labath wrote:
> > Hello Oleg, everyone,
> >
> > I have noticed something, which may be considered a race in the
> > interaction of ptrace and pseudoterminal interfaces. Basically, what
> > happens is this:
> > - we have two processes: A and B. B has the slave end of the pty open,
> > A has the master. A is tracing B.
> > - B writes some data through the slave end and then stops.
> > - A waits for B to stop.
> > - A does a select on the master pty endpoint. select returns there is
> > no data available
> > - later, A tries the select again, and this time the data appears.
>
> This happens because a separate kworker processes the input from slave
> and wakes the master. At the moment of select() on the master pty, the
> kworker has not processed the latest input (in fact it may only be
> scheduled and not running yet).
>
> Essentially, you're measuring a asynchronous i/o path with a synchronous
> method.

Thanks a lot Peter!

> > We are encountering this (very rare) issue in our debugger test suite,
> > where we check the stdout of the tracee to make sure it is behaving as
> > expected. I have attached a small program reproducing this behavior
> > (it fails after about 1000 iterations on a 3.13.0 kernel, I can retry
> > it on a newer kernel next week if you believe it might work there).
> > Interestingly, when I replace the pty with a regular pipe, it works as
> > expected (the data is available as soon as the program stops).
> >
> > My question is: Is this behavior something that you would consider a
> > bug? If yes, do you have any pointers, as to where I should look to
> > fix it?
>
> I don't consider it a bug.
>
> That said, I could see a couple of different ways to add this
> functionality:
> 1. Implement f_op->fsync() for ttys, which would flush the workqueue
>    (thus waiting for i/o completion). The debugger would fsync() before
>    select() on the master.
> 2. Automagically for ptraced processes. The basic idea would be that
>    writes to the slave end while a process was being ptraced would
>    set state that would trigger workqueue flush by select/poll/read of
>    the master end.

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.

Oleg.

--
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/