From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: jan.kratochvil@redhat.com, vda.linux@googlemail.com,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, indan@nul.nu, roland@hack.frob.com
Subject: Re: [PATCH 3/3] signal, ptrace: Fix delayed CONTINUED notification when ptraced
Date: Wed, 30 Mar 2011 21:29:18 +0200 [thread overview]
Message-ID: <20110330192918.GA14861@redhat.com> (raw)
In-Reply-To: <20110329144710.GC29865@htj.dyndns.org>
On 03/29, Tejun Heo wrote:
>
> Fix it by making job control continuation path use signal_wake_up()
> instead of wake_up_state() and recalc_sigpending_tsk() consider
> SIGNAL_CLD_MASK.
I still can't agree with this patch...
For the moment, please forget about ptrace. In this case this patch
is not needed, but it adds the small pessimization. OK, it is really
small, recalc_sigpending_tsk() is not called very often.
Also,
> After this patch, TIF_SIGPENDING is set for cases where it isn't
> strictly necessary; however, the only case which it makes any
> difference is when the SIGCONT is received while group stop is still
> in progress, which hardly is a case to optimize for.
Agreed. But, the current code is simply wrong even if the problem
is minor, and afaics your patch makes the things worse.
> @@ -652,6 +657,21 @@ void signal_wake_up(struct task_struct *t, int sig_type)
> mask = TASK_INTERRUPTIBLE;
> break;
>
> + case SIGCONT:
> + /*
> + * If there is a handler for SIGCONT, we must make sure
> + * that no thread returns to user mode before we post the
> + * signal, in case it was the only thread eligible to run
> + * the signal handler--then it must not do anything between
> + * resuming and running the handler. This is ensured by
> + * setting TIF_SIGPENDING before waking up.
> + */
> + mask = __TASK_STOPPED;
> + if (sig_user_defined(t, SIGCONT) &&
> + !sigismember(&t->blocked, SIGCONT))
> + mask |= TASK_INTERRUPTIBLE;
> + break;
> +
> case SIGTRAP:
> mask = TASK_INTERRUPTIBLE | __TASK_STOPPED | __TASK_TRACED;
> break;
> @@ -821,31 +841,9 @@ static int prepare_signal(int sig, struct task_struct *p, int from_ancestor_ns)
> rm_from_queue(SIG_KERNEL_STOP_MASK, &signal->shared_pending);
> t = p;
> do {
> [...snip...]
> - wake_up_state(t, state);
> + signal_wake_up(t, SIGCONT);
> } while_each_thread(p, t);
I don't think this logic should be moved into signal_wake_up(). Simply
because it is wrong.
Forget about SIGSTOP. Suppose that the thread group is running, and we
are doing tkill(SIGCONT). Now, why every thread gets TIF_SIGPENDING +
wakeup? This is not correct. Even the kill(SIGCONT) case is not exactly
right. This should be handled by complete_signal(). I think we had to
set TIF_SIGPENDING before, now the locking is different. I'll try to
make the patch.
Now, lets recall about ptrace. But please forget about the lost
notification. We are going to implement the new trap anyway. Ignoring
all details, how we can implement this? I think the most natural and
approach is something like this:
- add the new GROUP_STOP_CONTTRAP (the name is random), it
lives in task->group_stop
- this bit should be considered by recalc_sigpending_tsk()
along with GROUP_STOP_PENDING
- it should be set by prepare_signal(SIGCONT) if the task
is traced
- this bit should be checked by get_signal_to_deliver() to
trigger ptrace_stop()
Does this make any sense?
If yes, then everything works "automagically" after that. The tracee
will call get_signal_to_deliver() if it is running, and check
SIGNAL_CLD_MASK.
What do you think?
Oleg.
next prev parent reply other threads:[~2011-03-30 19:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 14:46 [PATCH 1/3] signal: Make signal_wake_up() take @sig_type instead of @resume Tejun Heo
2011-03-29 14:46 ` [PATCH 2/3] signal, ptrace: Add SIGTRAP signal_wake_up() Tejun Heo
2011-03-29 14:47 ` [PATCH 3/3] signal, ptrace: Fix delayed CONTINUED notification when ptraced Tejun Heo
2011-03-30 19:29 ` Oleg Nesterov [this message]
2011-03-31 7:29 ` Tejun Heo
2011-03-31 15:15 ` Oleg Nesterov
2011-03-31 16:34 ` Tejun Heo
2011-03-31 16:35 ` Tejun Heo
2011-03-31 17:29 ` Oleg Nesterov
2011-04-01 18:11 ` [PATCH 0/4] Was: " Oleg Nesterov
2011-04-01 18:11 ` [PATCH 1/4] signal: prepare_signal(SIGCONT) shouldn't play with TIF_SIGPENDING Oleg Nesterov
2011-04-01 18:12 ` [PATCH 2/4] signal: do_signal_stop: remove the unneeded task_clear_group_stop_pending() Oleg Nesterov
2011-04-01 18:12 ` [PATCH 3/4] signal: turn SIGNAL_STOP_DEQUEUED into GROUP_STOP_DEQUEUED Oleg Nesterov
2011-04-01 18:13 ` [PATCH 4/4] ptrace: ptrace_check_attach() should not do s/STOPPED/TRACED/ Oleg Nesterov
2011-04-04 0:11 ` [PATCH 0/4] Was: signal, ptrace: Fix delayed CONTINUED notification when ptraced Tejun Heo
2011-03-29 18:27 ` [PATCH 1/3] signal: Make signal_wake_up() take @sig_type instead of @resume Oleg Nesterov
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=20110330192918.GA14861@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=indan@nul.nu \
--cc=jan.kratochvil@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@hack.frob.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vda.linux@googlemail.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