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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to