From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: roland@redhat.com, jan.kratochvil@redhat.com,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org
Subject: Re: [PATCH 7/7] ptrace: clean transitions between TASK_STOPPED and TRACED
Date: Wed, 5 Jan 2011 17:35:42 +0100 [thread overview]
Message-ID: <20110105163542.GA19474@redhat.com> (raw)
In-Reply-To: <1293199257-11255-8-git-send-email-tj@kernel.org>
To me, the whole series is fine.
As for the user-visible changes, I believe they are carefully documented,
hopefully Roland and Jan can take a look.
This patch looks good too, a couple of minor nits below.
On 12/24, Tejun Heo wrote:
>
> + * task_clear_group_stop_trapping - clear group stop trapping bit
> + * @task: target task
> + *
> + * If GROUP_STOP_TRAPPING is set, a ptracer is waiting for us. Clear it
> + * and wake up the ptracer. Note that we don't need any further locking.
> + * @task->siglock guarantees that @task->parent points to the ptracer.
> + *
> + * CONTEXT:
> + * Must be called with @task->sighand->siglock held.
> + */
> +static void task_clear_group_stop_trapping(struct task_struct *task)
> +{
> + if (unlikely(task->group_stop & GROUP_STOP_TRAPPING)) {
> + task->group_stop &= ~GROUP_STOP_TRAPPING;
> + __wake_up_sync(&task->parent->signal->wait_chldexit,
> + TASK_UNINTERRUPTIBLE, 1);
OK... we are doing __wake_up_sync_key(key => NULL), this looks unfriendly
to child_wait_callback(). But TASK_UNINTERRUPTIBLE means we can't abuse
the tracer's subthreads doing do_wait().
> void task_clear_group_stop(struct task_struct *task)
> {
> task->group_stop &= ~(GROUP_STOP_PENDING | GROUP_STOP_CONSUME);
> + task_clear_group_stop_trapping(task);
> }
Not a comment, but the question. I am not sure task_clear_group_stop()
needs task_clear_group_stop_trapping(), please see below...
> @@ -1694,6 +1716,14 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
> }
>
> /*
> + * We're committing to trapping. Clearing GROUP_STOP_TRAPPING and
> + * transition to TASK_TRACED should be atomic with respect to
> + * siglock. Do it after the arch hook as siglock is released and
> + * regrabbed across it.
> + */
> + task_clear_group_stop_trapping(current);
This wakes up the tracer. It can return from sys_ptrace(), call do_wait(),
and take tasklist_lock before us.
Of course, this is only theoretical problem, but perhaps it makes sense
to do this after __set_current_state(TASK_TRACED), otherwise
task_stopped_code() can fail.
> @@ -1839,13 +1875,25 @@ static int do_signal_stop(int signr)
> schedule();
>
> spin_lock_irq(¤t->sighand->siglock);
> - } else
> - ptrace_stop(current->exit_code, CLD_STOPPED, 0, NULL);
> + } else {
> + ptrace_stop(current->group_stop & GROUP_STOP_SIGMASK,
> + CLD_STOPPED, 0, NULL);
> + current->exit_code = 0;
> + }
> +
> + /*
> + * GROUP_STOP_PENDING could be set if another group stop has
> + * started since being woken up or ptrace wants us to transit
> + * between TASK_STOPPED and TRACED. Retry group stop.
> + */
> + if (current->group_stop & GROUP_STOP_PENDING) {
> + WARN_ON_ONCE(!(current->group_stop & GROUP_STOP_SIGMASK));
> + goto retry;
> + }
>
> spin_unlock_irq(¤t->sighand->siglock);
Can't we add task_clear_group_stop_trapping() right before we drop
->siglock ? This way we can remove it from task_clear_group_stop(),
afaics. Once again, this is up to you. Looks more clean to me, but
this is of course subjective.
If GROUP_STOP_PENDING is not set, but GROUP_STOP_TRAPPING is set,
then this task was SIGKILL'ed or SIGCONT'ed, we can notify the
tracer.
Otherwise (ignoring ptrace_stop), there is no reasons to check
GROUP_STOP_TRAPPING. It was set under ->siglock when the tracee
was in TASK_STOPPED state few lines above.
Oleg.
next prev parent reply other threads:[~2011-01-05 16:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-24 14:00 [PATCHSET RFC] ptrace,signal: clean transition between STOPPED and TRACED Tejun Heo
2010-12-24 14:00 ` [PATCH 1/7] clone: kill CLONE_STOPPED Tejun Heo
2011-01-17 22:17 ` Roland McGrath
2011-01-27 13:13 ` Tejun Heo
2010-12-24 14:00 ` [PATCH 2/7] ptrace: add @why to ptrace_stop() Tejun Heo
2010-12-24 14:00 ` [PATCH 3/7] signal: fix premature completion of group stop when interfered by ptrace Tejun Heo
2010-12-24 14:00 ` [PATCH 4/7] signal: use GROUP_STOP_PENDING to stop once for a single group stop Tejun Heo
2010-12-24 14:00 ` [PATCH 5/7] ptrace: participate in group stop from ptrace_stop() iff the task is trapping for " Tejun Heo
2010-12-24 14:00 ` [PATCH 6/7] ptrace: make do_signal_stop() use ptrace_stop() if the task is being ptraced Tejun Heo
2010-12-24 14:00 ` [PATCH 7/7] ptrace: clean transitions between TASK_STOPPED and TRACED Tejun Heo
2011-01-05 16:35 ` Oleg Nesterov [this message]
2011-01-09 22:05 ` Tejun Heo
2011-01-13 16:03 ` Jan Kratochvil
2011-01-12 13:23 ` [PATCHSET RFC] ptrace,signal: clean transition between STOPPED " Tejun Heo
2011-01-12 18:10 ` Roland McGrath
2011-01-12 21:43 ` Jan Kratochvil
2011-01-13 15:05 ` Tejun Heo
2011-01-13 15:51 ` Oleg Nesterov
2011-01-18 2:11 ` Roland McGrath
2011-01-27 13:23 ` Tejun Heo
2011-01-28 21:06 ` Roland McGrath
2011-01-18 2:14 ` Roland McGrath
2011-01-27 15:46 ` Tejun Heo
2011-01-27 17:48 ` Tejun Heo
2011-01-28 20:40 ` Roland McGrath
2011-01-31 15:41 ` Tejun Heo
2011-01-31 15:54 ` Oleg Nesterov
2011-01-31 16:07 ` Tejun Heo
2011-02-01 10:35 ` Tejun Heo
2011-02-02 5:39 ` 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=20110105163542.GA19474@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jan.kratochvil@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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.