From: Oleg Nesterov <oleg@redhat.com>
To: Matthew Dempsky <mdempsky@chromium.org>
Cc: Kees Cook <keescook@chromium.org>,
Julien Tinnes <jln@chromium.org>,
Roland McGrath <mcgrathr@chromium.org>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] ptrace: Fix fork event messages across pid namespaces
Date: Wed, 2 Apr 2014 16:58:50 +0200 [thread overview]
Message-ID: <20140402145850.GB7332@redhat.com> (raw)
In-Reply-To: <1396391358-22367-1-git-send-email-mdempsky@chromium.org>
On 04/01, Matthew Dempsky wrote:
>
> @@ -1605,10 +1605,12 @@ long do_fork(unsigned long clone_flags,
> */
> if (!IS_ERR(p)) {
> struct completion vfork;
> + struct pid *pid;
>
> trace_sched_process_fork(current, p);
>
> - nr = task_pid_vnr(p);
> + pid = get_task_pid(p, PIDTYPE_PID);
So you decided to use get_pid/put_pid ;) Honestly, I'd prefer to just
calculate "pid_t trace_pid" before wake_up_new_task(), but I won't
argue. Plus this way the race window becomes really small, OK.
> + if (unlikely(trace)) {
> + /*
> + * We want to report the child's pid as seen from the
> + * tracer's pid namespace.
> + * FIXME: We still risk sending a bogus event message if
> + * debuggers from different pid namespaces detach and
> + * reattach between rcu_read_unlock() and ptrace_stop().
> + */
> + unsigned long message;
> + rcu_read_lock();
> + message = pid_nr_ns(pid,
> + task_active_pid_ns(current->parent));
> + rcu_read_unlock();
> + ptrace_event(trace, message);
> + }
>
> if (clone_flags & CLONE_VFORK) {
> - if (!wait_for_vfork_done(p, &vfork))
> - ptrace_event(PTRACE_EVENT_VFORK_DONE, nr);
> + if (!wait_for_vfork_done(p, &vfork)) {
> + /* See comment above about pid namespaces. */
> + unsigned long message;
> + rcu_read_lock();
> + message = pid_nr_ns(pid,
> + task_active_pid_ns(current->parent));
> + rcu_read_unlock();
> + ptrace_event(PTRACE_EVENT_VFORK_DONE, message);
> + }
OK, but may I suggest you to make a helper? Note that the code under
"if (trace)" and "if (CLONE_VFORK)" is the same. Even the comment above
equally applies to the CLONE_VFORK branch.
Especially because this code needs a fix. Yes, rcu_read_lock() should
be enough to ensure that ->parent and its namespace (if !NULL) can not
go away, but task_active_pid_ns() can return NULL release_task(->parent)
was already (although this race is pure theoretical). So this helper
should also check it is !NULL under rcu_read_lock(), afaics.
(Hmm... off-topic, but get_pidns looks buggy by the same reason, I'll
send a fix).
And I forgot to mention, please send v5 to akpm. We usually route ptrace
patches via -mm tree.
Oleg.
next prev parent reply other threads:[~2014-04-02 15:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1396288478-1314-1-git-send-email-mdempsky@chromium.org>
[not found] ` <20140331181651.GA27686@redhat.com>
[not found] ` <CAF52+S5i7oqJnJ1NN0bk5Vg=CiYrussw0AunteE72kMMcWkeJA@mail.gmail.com>
2014-04-01 18:52 ` [PATCH v2] Fix ptrace events across pid namespaces Oleg Nesterov
2014-04-01 20:44 ` Matthew Dempsky
2014-04-01 22:29 ` [PATCH v3] ptrace: Fix fork event messages " Matthew Dempsky
2014-04-02 0:39 ` Matthew Dempsky
2014-04-02 14:58 ` Oleg Nesterov [this message]
2014-04-02 15:44 ` [PATCH 0/1] pid_namespace: pidns_get() should check task_active_pid_ns() != NULL Oleg Nesterov
2014-04-02 15:45 ` [PATCH 1/1] " Oleg Nesterov
2014-04-02 16:53 ` Eric W. Biederman
2014-04-02 15:58 ` Oleg Nesterov
2014-04-02 22:01 ` Eric W. Biederman
2014-04-02 21:58 ` [PATCH v3] ptrace: Fix fork event messages across pid namespaces Matthew Dempsky
2014-04-02 22:37 ` Matthew Dempsky
2014-04-07 19:24 ` Oleg Nesterov
2014-04-03 2:26 ` [PATCH v4] " Matthew Dempsky
2014-04-03 15:44 ` Oleg Nesterov
2014-04-03 16:13 ` Oleg Nesterov
2014-04-03 18:07 ` Matthew Dempsky
2014-04-07 19:06 ` Oleg Nesterov
2014-04-29 20:20 ` [RESEND PATCH " Matthew Dempsky
2014-04-29 22:11 ` Andrew Morton
2014-04-30 0:34 ` [PATCH v5] " Matthew Dempsky
2014-04-30 11:51 ` Oleg Nesterov
2014-04-30 20:16 ` Andrew Morton
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=20140402145850.GB7332@redhat.com \
--to=oleg@redhat.com \
--cc=jan.kratochvil@redhat.com \
--cc=jln@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrathr@chromium.org \
--cc=mdempsky@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.