From: Oleg Nesterov <oleg@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt_tracer
Date: Thu, 28 May 2009 00:41:40 +0200 [thread overview]
Message-ID: <20090527224140.GC6770@redhat.com> (raw)
In-Reply-To: <20090527021131.4778BFC36B@magilla.sf.frob.com>
On 05/26, Roland McGrath wrote:
>
> > But is the current code correct? If we are not traced any longer
> > si_pid/si_uid are not necessary right either, we should calculate them
> > before ptrace_stop(), no?
>
> Yes, though nothing really cares about these values for such cases.
> (It's really only there for dealing with debuggers that were written
> before PTRACE_SETSIGINFO was invented.)
>
> It's probably best now to clean this up so that this logic is
> applied in the tracer causing the resumption rather than in the
> tracee. i.e. do it in ptrace_resume() and ptrace_detach().
Hmm. Didn't think about this, and I agree this looks nicer...
So, we need something like
void ptrace_set_exit_code(struct task_struct *child, int exit_code)
{
unsigned long flags;
if (!exit_code)
child->exit_code = exit_code;
if (child->exit_code == exit_code)
return;
if (lock_task_sighand(child, &flags)) {
siginfo_t *info = child->last_siginfo;
if (info && info->info->si_signo != exit_code) {
info->si_signo = exit_code;
info->si_errno = 0;
info->si_code = SI_USER;
info->si_pid = task_pid_nr_ns(current, child->nsproxy->pid_ns);
info->si_uid = task_uid(current);
}
child->exit_code = exit_code;
unlock_task_sighand(child, &flags);
}
}
And ptrace_resume/ptrace_detach should use ptrace_set_exit_code()
instead of child->exit_code = data.
The disadvantage is, ptrace_notify() does not need this, we add the
little pessimization...
And. This change adds another dependency with arches which implement
their own resume.
So. Do you think this cleanup should be done before/with this series
or we can do it later?
Oleg.
next prev parent reply other threads:[~2009-05-27 22:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-25 0:00 [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt_tracer Oleg Nesterov
2009-05-25 21:59 ` Oleg Nesterov
2009-05-25 22:39 ` [RFC PATCH 8/X] ptrace: introduce ptrace_tracer() helper Oleg Nesterov
2009-05-27 2:45 ` Roland McGrath
2009-05-27 21:45 ` Oleg Nesterov
2009-05-27 22:24 ` Roland McGrath
2009-05-27 2:11 ` [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt_tracer Roland McGrath
2009-05-27 22:41 ` Oleg Nesterov [this message]
2009-05-27 23:05 ` ptrace && task->exit_code Oleg Nesterov
2009-05-27 23:21 ` Roland McGrath
2009-05-29 19:06 ` Oleg Nesterov
2009-06-01 2:16 ` Roland McGrath
2009-05-27 23:07 ` [RFC PATCH 7/X] ptrace: mv task->parent ptrace_task->pt_tracer Roland McGrath
2009-05-27 23:59 ` Oleg Nesterov
2009-05-28 0:32 ` Roland McGrath
2009-05-28 2:54 ` Oleg Nesterov
2009-05-28 3:19 ` Roland McGrath
2009-05-28 3:35 ` Oleg Nesterov
2009-05-28 19:28 ` Roland McGrath
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=20090527224140.GC6770@redhat.com \
--to=oleg@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@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