All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: roland@redhat.com, linux-kernel@vger.kernel.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	"rjw@sisk.plpavel"@ucw.cz
Subject: Re: [PATCH 06/14] signal: use GROUP_STOP_PENDING to avoid stopping multiple times for a single group stop
Date: Fri, 26 Nov 2010 18:59:45 +0100	[thread overview]
Message-ID: <20101126175945.GE28177@redhat.com> (raw)
In-Reply-To: <1290768569-16224-7-git-send-email-tj@kernel.org>

I am stucked at this point ;)

On 11/26, Tejun Heo wrote:
>
> Currently task->signal->group_stop_count is used to decide whether to
> stop for group stop.  However, if there is a task in the group which
> is taking a long time to stop, other tasks which are continued by
> ptrace would repeatedly stop for the same group stop until the group
> stop is complete.

Yes. but the tracee won't abuse ->group_stop_count, this was fixed
by the previous patch.

But, otoh, what if debugger resumes the tracee when the group stop
was completed by other sub-threads ?

The tracee will run with GROUP_STOP_PENDING set. ->group_stop_count
is zero. If this tracee recieves a signal (or spurious TIF_SIGPENDING),
suddenly it will notice GROUP_STOP_PENDING and report the stop to
debugger.

This looks a bit strange. OK, perhaps it makes sense to report the
stop to "ack" the group stop which wasn't acked in ptrace_stop().
Or, if it was untraced after resume, it makes sense to "silently"
stop as well.

But, in this case it shouldn't wait until signal_pending() is true?


> @@ -1742,8 +1745,8 @@ static int do_signal_stop(int signr)
>  	struct signal_struct *sig = current->signal;
>  	int notify = 0;
>
> -	if (!sig->group_stop_count) {
> -		unsigned int gstop = GROUP_STOP_CONSUME;
> +	if (!(current->group_stop & GROUP_STOP_PENDING)) {
> +		unsigned int gstop = GROUP_STOP_PENDING | GROUP_STOP_CONSUME;
>  		struct task_struct *t;

Hmm. This means, the ptraced task can initiate the group stop
while it is already in progress...

Debugger can constantly resume a tracee while the group stop
is not finished. Finally this tracee can dequeue SIGSTOP without
GROUP_STOP_PENDING.

At first glance, nothing bad can happen, but I am not sure.
We can have other ptraced threads which were resumed after
ptrace_stop()/do_signal_stop().



> This will change with future patches.

Yes. I tried to study this series patch-by-patch. I think I should
read the whole series to really understand the intermediate changes.
I'll try to return on Monday.

Cough. I didn't expect I forgot this code that much ;)

Oleg.


  reply	other threads:[~2010-11-26 18:06 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-26 10:49 [PATCHSET RFC] ptrace,signal: sane interaction between ptrace and job control signals Tejun Heo
2010-11-26 10:49 ` [PATCH 01/14] signal: fix SIGCONT notification code Tejun Heo
2010-11-26 13:49   ` Oleg Nesterov
2010-12-01  1:43   ` Roland McGrath
2010-11-26 10:49 ` [PATCH 02/14] freezer: fix a race during freezing of TASK_STOPPED tasks Tejun Heo
2010-11-26 19:40   ` Rafael J. Wysocki
2010-11-26 19:59     ` Tejun Heo
2010-11-26 10:49 ` [PATCH 03/14] freezer: remove superflous try_to_freeze() loop in do_signal_stop() Tejun Heo
2010-11-26 19:42   ` Rafael J. Wysocki
2010-11-26 10:49 ` [PATCH 04/14] signal: don't notify parent if not stopping after tracehook_notify_jctl() " Tejun Heo
2010-11-26 14:46   ` Oleg Nesterov
2010-11-26 15:04     ` Tejun Heo
2010-11-26 10:49 ` [PATCH 05/14] signal: fix premature completion of group stop when interfered by ptrace Tejun Heo
2010-11-26 15:40   ` Oleg Nesterov
2010-11-26 16:03     ` Tejun Heo
2010-11-26 10:49 ` [PATCH 06/14] signal: use GROUP_STOP_PENDING to avoid stopping multiple times for a single group stop Tejun Heo
2010-11-26 17:59   ` Oleg Nesterov [this message]
2010-11-26 18:39     ` Tejun Heo
2010-11-27 11:40   ` [PATCH UPDATED " Tejun Heo
2010-11-28 19:07     ` Oleg Nesterov
2010-11-29 13:38       ` Tejun Heo
2010-11-26 10:49 ` [PATCH 07/14] ptrace: add @why to ptrace_stop() Tejun Heo
2010-11-26 10:49 ` [PATCH 08/14] ptrace: make do_signal_stop() use ptrace_stop() if the task is being ptraced Tejun Heo
2010-11-28 19:54   ` Oleg Nesterov
2010-11-28 20:22     ` Jan Kratochvil
2010-11-28 20:53       ` Oleg Nesterov
2010-11-26 10:49 ` [PATCH 09/14] ptrace: clean transitions between TASK_STOPPED and TRACED Tejun Heo
2010-11-28 20:25   ` Oleg Nesterov
2010-11-28 20:51     ` Jan Kratochvil
2010-11-29 13:48     ` Tejun Heo
2010-11-26 10:49 ` [PATCH 10/14] ptrace: don't consume group count from ptrace_stop() Tejun Heo
2010-11-26 10:49 ` [PATCH 11/14] ptrace: make group stop notification reliable against ptrace Tejun Heo
2010-11-28 20:30   ` Oleg Nesterov
2010-11-29 13:52     ` Tejun Heo
2010-11-26 10:49 ` [PATCH 12/14] ptrace: reorganize __ptrace_unlink() and ptrace_untrace() Tejun Heo
2010-11-26 10:49 ` [PATCH 13/14] ptrace: make SIGCONT notification reliable against ptrace Tejun Heo
2010-11-26 10:49 ` [PATCH 14/14] ptrace: remove the extra wake_up_process() from ptrace_detach() Tejun Heo
2010-11-28 20:44   ` Oleg Nesterov
2010-11-29 13:55     ` Tejun Heo
2010-11-26 10:55 ` [PATCHSET RFC] ptrace,signal: sane interaction between ptrace and job control signals Tejun Heo

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=20101126175945.GE28177@redhat.com \
    --to=oleg@redhat.com \
    --cc="rjw@sisk.plpavel"@ucw.cz \
    --cc=akpm@linux-foundation.org \
    --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.