From: Keno Fischer <keno@juliacomputing.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?
Date: Tue, 13 Sep 2016 17:57:56 -0400 [thread overview]
Message-ID: <CABV8kRxgehztk2SnLRF7zz942w=M=R9gkabZKS95icQhjEFgdw@mail.gmail.com> (raw)
In-Reply-To: <20160823153428.GB4067@redhat.com>
Hi Oleg,
I have another obscure ptrace question which seems somewhat related,
so let me ask it here.
Consider this:
```
static int sigchld_counter = 0;
void sigchld_handler(int sig) {
(void)sig;
sigchld_counter++;
}
int main(void) {
signal(SIGCHLD, sigchld_handler);
pid_t child;
if (0 == (child = fork())) {
raise(SIGSTOP);
assert(0); // Should never be continued
}
// Wait until stopped
int status;
pid_t wret = waitpid(child, &status, __WALL | WSTOPPED);
assert(wret == child);
assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP);
assert(sigchld_counter == 1);
// Now PTRACE_SEIZE the child
long err = ptrace(PTRACE_SEIZE, child, NULL, (void*)PTRACE_O_TRACESYSGOOD);
assert(err == 0);
// Make sure that didn't cause a notification
wret = waitpid(child, &status, __WALL | WSTOPPED | WNOHANG);
assert(wret == 0);
assert(sigchld_counter == 1);
}
```
I wouldn't have expected the PTRACE_SEIZE to generate another
SIGCHLD/be waitable again,
(the last two assertions fail).
Is that supposed to happen? If so, I'd like to update the man page to
mention this behavior, but
I wanted to check with you first.
Thanks,
Keno
On Tue, Aug 23, 2016 at 11:34 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 08/18, Keno Fischer wrote:
>>
>> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>> >
>> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
>> > PTRACE_INTERRUPT, you know that the tracee did not report the "new"
>> > SIGTTIN.
>>
>> It seems possible to remember whether or not we injected a stopping
>> signal and if so the next PTRACE_EVENT_STOP is a group-stop, otherwise
>> a PTRACE_INTERRUPT stop. Currently what I do is the other way around,
>> after issuing PTRACE_INTERRUPT, the first (if any) of the next two
>> stops that is a PTRACE_EVENT_STOP get interpreted as a
>> PTRACE_INTERRUPT stop. I haven't thought through this fully yet, so I
>> can't give you a concrete example I worried about, it just seems
>> fragile compared to just checking whether WSTOPSIG() == SIGTRAP.
>
> Yes, I see your point. And to remind, I was confused too.
>
> Perhaps we can add another THIS_SIGNAL_WAS_ALREADY_REPORTED bit, but
> you know, I'd prefer to avoid another subtle change in behaviour. You
> can never know if it is "safe" or not when it comes to ptrace, perhaps
> some application already relies on this WSTOPSIG().
>
> Oleg.
>
prev parent reply other threads:[~2016-09-13 21:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 3:52 ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered? Keno Fischer
2016-08-18 14:37 ` Oleg Nesterov
2016-08-18 15:38 ` Oleg Nesterov
2016-08-18 16:23 ` Oleg Nesterov
2016-08-18 17:37 ` Keno Fischer
2016-08-23 15:34 ` Oleg Nesterov
2016-09-13 21:57 ` Keno Fischer [this message]
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='CABV8kRxgehztk2SnLRF7zz942w=M=R9gkabZKS95icQhjEFgdw@mail.gmail.com' \
--to=keno@juliacomputing.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@hack.frob.com \
--cc=tj@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).