Re: rcu_preempt detected stalls.

[Oleg Nesterov]

On 10/23, Paul E. McKenney wrote:
>
> OK, so making each pass through the loop a separate RCU read-side critical
> section might be considered to be suppressing notification of an error
> condition?

I agree, this change probably makes sense anyway. Personally I'd prefer
the version below (somehow I hate multiple unlock's), but I won't insist.

Oleg.

--- x/kernel/signal.c
+++ x/kernel/signal.c
@@ -1331,21 +1331,19 @@ int kill_pid_info(int sig, struct siginf
 	int error = -ESRCH;
 	struct task_struct *p;
 
-	rcu_read_lock();
 retry:
+	rcu_read_lock();
 	p = pid_task(pid, PIDTYPE_PID);
-	if (p) {
+	if (p)
 		error = group_send_sig_info(sig, info, p);
-		if (unlikely(error == -ESRCH))
-			/*
-			 * The task was unhashed in between, try again.
-			 * If it is dead, pid_task() will return NULL,
-			 * if we race with de_thread() it will find the
-			 * new leader.
-			 */
-			goto retry;
-	}
 	rcu_read_unlock();
+	/*
+	 * The task was unhashed in between, try again. If it is dead,
+	 * pid_task() will return NULL, if we race with de_thread() it
+	 * will find the new leader.
+	 */
+	if (p && error == -ESRCH))
+		goto retry;
 
 	return error;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/