All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
	josh@joshtriplett.org, dvhltc@us.ibm.com, niv@us.ibm.com,
	tglx@linutronix.de, rostedt@goodmis.org, Valdis.Kletnieks@vt.edu,
	dhowells@redhat.com, eric.dumazet@gmail.com
Subject: Re: [PATCH tip/core/urgent 3/3] sched: protect __sched_setscheduler() access to cgroups
Date: Thu, 22 Apr 2010 14:25:43 -0700	[thread overview]
Message-ID: <20100422212543.GO2524@linux.vnet.ibm.com> (raw)
In-Reply-To: <1271968398.1646.16.camel@laptop>

On Thu, Apr 22, 2010 at 10:33:18PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-04-22 at 12:54 -0700, Paul E. McKenney wrote:
> > A given task's cgroups structures must remain while that task is running
> > due to reference counting, so this is presumably a false positive.
> > Updated to reflect feedback from Tetsuo Handa.
> 
> I think its not a false positive, I think we can race with the task
> being placed in another cgroup. We don't hold task_lock() [our other
> discussion] nor does it hold rq->lock [used by the sched ->attach()
> method].

Ah, I am dropping this patch then.

Ingo, please accept my apologies for the confusion submitting it too soon!

							Thanx, Paul

> That said, we should probably cure the race condition of
> sched_setscheduler() vs ->attach().
> 
> Something like the below perhaps?
> 
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ---
>  kernel/sched.c |   38 ++++++++++++++++++++++++++------------
>  1 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 95eaecc..345df67 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -4425,16 +4425,6 @@ recheck:
>  	}
> 
>  	if (user) {
> -#ifdef CONFIG_RT_GROUP_SCHED
> -		/*
> -		 * Do not allow realtime tasks into groups that have no runtime
> -		 * assigned.
> -		 */
> -		if (rt_bandwidth_enabled() && rt_policy(policy) &&
> -				task_group(p)->rt_bandwidth.rt_runtime == 0)
> -			return -EPERM;
> -#endif
> -
>  		retval = security_task_setscheduler(p, policy, param);
>  		if (retval)
>  			return retval;
> @@ -4450,6 +4440,28 @@ recheck:
>  	 * runqueue lock must be held.
>  	 */
>  	rq = __task_rq_lock(p);
> +	retval = 0;
> +#ifdef CONFIG_RT_GROUP_SCHED
> +	if (user) {
> +		/*
> +		 * Do not allow realtime tasks into groups that have no runtime
> +		 * assigned.
> +		 *
> +		 * RCU read lock not strictly required but here for PROVE_RCU,
> +		 * the task is pinned by holding rq->lock which avoids races
> +		 * with ->attach().
> +		 */
> +		rcu_read_lock();
> +		if (rt_bandwidth_enabled() && rt_policy(policy) &&
> +				task_group(p)->rt_bandwidth.rt_runtime == 0)
> +			retval = -EPERM;
> +		rcu_read_unlock();
> +
> +		if (retval)
> +			goto unlock;
> +	}
> +#endif
> +
>  	/* recheck policy now with rq lock held */
>  	if (unlikely(oldpolicy != -1 && oldpolicy != p->policy)) {
>  		policy = oldpolicy = -1;
> @@ -4477,12 +4489,14 @@ recheck:
> 
>  		check_class_changed(rq, p, prev_class, oldprio, running);
>  	}
> +unlock:
>  	__task_rq_unlock(rq);
>  	raw_spin_unlock_irqrestore(&p->pi_lock, flags);
> 
> -	rt_mutex_adjust_pi(p);
> +	if (!retval)
> +		rt_mutex_adjust_pi(p);
> 
> -	return 0;
> +	return retval;
>  }
> 
>  /**
> 
> 

      reply	other threads:[~2010-04-22 21:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22 19:53 [PATCH tip/core/urgent] Fix RCU lockdep splats in keys and sched Paul E. McKenney
2010-04-22 19:54 ` [PATCH tip/core/urgent 1/3] KEYS: Fix an RCU warning Paul E. McKenney
2010-04-22 19:54 ` [PATCH tip/core/urgent 2/3] KEYS: Fix an RCU warning in the reading of user keys Paul E. McKenney
2010-04-22 19:54 ` [PATCH tip/core/urgent 3/3] sched: protect __sched_setscheduler() access to cgroups Paul E. McKenney
2010-04-22 20:33   ` Peter Zijlstra
2010-04-22 21:25     ` Paul E. McKenney [this message]

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=20100422212543.GO2524@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=eric.dumazet@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=niv@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.