From: Peter Hurley <peter@hurleysoftware.com>
To: Pavel Labath <labath@google.com>, Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: ptrace and pseudoterminals
Date: Wed, 4 Nov 2015 12:02:42 -0500 [thread overview]
Message-ID: <563A3A32.2030102@hurleysoftware.com> (raw)
In-Reply-To: <CAJt8pk_DJbjHFvGiyeg1w62trZjgeGm=2Nrx7iHORCRtXHAyow@mail.gmail.com>
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.
> 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.
Regards,
Peter Hurley
next prev parent reply other threads:[~2015-11-04 17:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 23:16 ptrace and pseudoterminals Pavel Labath
2015-11-04 17:02 ` Peter Hurley [this message]
2015-11-04 19:43 ` Oleg Nesterov
2015-11-05 13:25 ` Peter Hurley
2015-11-05 18:35 ` Pavel Labath
2015-11-05 20:29 ` Peter Hurley
2015-11-18 10:10 ` Pavel Labath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563A3A32.2030102@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=labath@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox