All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	htejun@gmail.com
Subject: Re: rcu_preempt detected stalls.
Date: Thu, 23 Oct 2014 13:24:44 -0700	[thread overview]
Message-ID: <20141023202443.GE4977@linux.vnet.ibm.com> (raw)
In-Reply-To: <20141023195337.GA7768@redhat.com>

On Thu, Oct 23, 2014 at 09:53:37PM +0200, Oleg Nesterov wrote:
> 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.

Your code, your rules.  ;-)

But given this structure, why not use a for() loop replace the
"goto retry" with an inverted condition and a "return error"?
Maybe something like the following patch?

							Thanx, Paul

------------------------------------------------------------------------

signal: Exit RCU read-side critical section on each pass through loop

The kill_pid_info() can potentially loop indefinitely if tasks are created
and deleted sufficiently quickly, and if this happens, this function
will remain in a single RCU read-side critical section indefinitely.
This commit therefore exits the RCU read-side critical section on each
pass through the loop.  Because a race must happen to retry the loop,
this should have no performance impact in the common case.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>

diff --git a/kernel/signal.c b/kernel/signal.c
index 8f0876f9f6dd..54820984a872 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1331,23 +1331,21 @@ int kill_pid_info(int sig, struct siginfo *info, struct pid *pid)
 	int error = -ESRCH;
 	struct task_struct *p;
 
-	rcu_read_lock();
-retry:
-	p = pid_task(pid, PIDTYPE_PID);
-	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();
+	for (;;) {
+		rcu_read_lock();
+		p = pid_task(pid, PIDTYPE_PID);
+		if (p)
+			error = group_send_sig_info(sig, info, p);
+		rcu_read_unlock();
+		if (likely(!p || error != -ESRCH))
+			return error;
 
-	return error;
+		/*
+		 * 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.
+		 */
+	}
 }
 
 int kill_proc_info(int sig, struct siginfo *info, pid_t pid)


  reply	other threads:[~2014-10-23 20:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-13 17:35 rcu_preempt detected stalls Dave Jones
2014-10-15  2:35 ` Sasha Levin
2014-10-23 18:39   ` Paul E. McKenney
2014-10-23 18:55     ` Sasha Levin
2014-10-23 19:58       ` Paul E. McKenney
2014-10-24 12:28         ` Sasha Levin
2014-10-24 16:13           ` Paul E. McKenney
2014-10-24 16:39             ` Sasha Levin
2014-10-27 21:13               ` Paul E. McKenney
2014-10-27 23:44                 ` Paul E. McKenney
2014-10-27 23:44                   ` Paul E. McKenney
2014-11-13 23:07                   ` Paul E. McKenney
2014-11-13 23:07                     ` Paul E. McKenney
2014-11-13 23:10                     ` Sasha Levin
2014-11-13 23:10                       ` Sasha Levin
2014-10-30 23:41                 ` Sasha Levin
2014-10-23 18:32 ` Paul E. McKenney
2014-10-23 18:40   ` Dave Jones
2014-10-23 19:28     ` Paul E. McKenney
2014-10-23 19:37       ` Dave Jones
2014-10-23 19:52         ` Paul E. McKenney
2014-10-23 20:28           ` Dave Jones
2014-10-23 20:44             ` Paul E. McKenney
2014-10-23 19:13   ` Oleg Nesterov
2014-10-23 19:38     ` Paul E. McKenney
2014-10-23 19:53       ` Oleg Nesterov
2014-10-23 20:24         ` Paul E. McKenney [this message]
2014-10-23 21:13           ` Oleg Nesterov
2014-10-23 21:38             ` Paul E. McKenney
2014-10-25  3:16 ` Dâniel Fraga
2021-08-31 15:21 Jorge Ramirez-Ortiz, Foundries
2021-08-31 15:21 ` Jorge Ramirez-Ortiz, Foundries
2021-08-31 15:53 ` Paul E. McKenney
2021-08-31 15:53   ` Paul E. McKenney
2021-08-31 17:01 ` Zhouyi Zhou
2021-08-31 17:01   ` Zhouyi Zhou
2021-08-31 17:01     ` Zhouyi Zhou
2021-08-31 17:11     ` Zhouyi Zhou
2021-08-31 17:11       ` Zhouyi Zhou
2021-08-31 17:11         ` Zhouyi Zhou
2021-09-01  1:03         ` Zhouyi Zhou
2021-09-01  1:03           ` Zhouyi Zhou
2021-09-01  1:03             ` Zhouyi Zhou
2021-09-01  4:08             ` Neeraj Upadhyay
2021-09-01  6:47               ` Zhouyi Zhou
2021-09-01  6:47                 ` Zhouyi Zhou
2021-09-01  6:47                   ` Zhouyi Zhou
2021-09-01  8:23             ` Jorge Ramirez-Ortiz, Foundries
2021-09-01  8:23               ` Jorge Ramirez-Ortiz, Foundries
2021-09-01  9:17               ` Zhouyi Zhou
2021-09-01  9:17                 ` Zhouyi Zhou
2021-09-01  9:17                   ` Zhouyi Zhou

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=20141023202443.GE4977@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=davej@redhat.com \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.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 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.