[PATCH 10/14] ptrace: don't consume group count from ptrace_stop()

[Tejun Heo <tj@kernel.org>]

Now that group stop pending and consumed states are properly tracked
per task, there is no need to consume group_stop_count from
ptrace_stop() which is inaccurate.

The only behavior change is the increased likelihood of missing
notifications for group stops if the thread group contains one or more
ptraced tasks, but they never were reliable in the presence of ptraced
tasks.  With this change, consume_group_stop() is called only if group
stop is pending.  Make sure it is so by adding WARN_ON_ONCE().

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
---
 kernel/signal.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 8341667..c084ea8 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -225,6 +225,8 @@ static inline void print_dropped_signal(int sig)
 
 static bool consume_group_stop(void)
 {
+	WARN_ON_ONCE(!(current->group_stop & GROUP_STOP_PENDING));
+
 	if (!(current->group_stop & GROUP_STOP_CONSUME))
 		return false;
 
@@ -1657,13 +1659,6 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
 			return;
 	}
 
-	/*
-	 * If there is a group stop in progress,
-	 * we must participate in the bookkeeping.
-	 */
-	if (current->signal->group_stop_count > 0)
-		consume_group_stop();
-
 	current->last_siginfo = info;
 	current->exit_code = exit_code;
 
-- 
1.7.1