[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180614094518.00a181cf@gandalf.local.home>
Date: Thu, 14 Jun 2018 09:45:18 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: peterz@...radead.org, mingo@...hat.com,
linux-kernel@...r.kernel.org, luca.abeni@...tannapisa.it,
claudio@...dence.eu.com, tommaso.cucinotta@...tannapisa.it,
bristot@...hat.com, mathieu.poirier@...aro.org, lizefan@...wei.com,
cgroups@...r.kernel.org
Subject: Re: [PATCH v4 4/5] sched/core: Prevent race condition between
cpuset and __sched_setscheduler()
On Wed, 13 Jun 2018 14:17:10 +0200
Ju
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index b42037e6e81d..d26fd4795aa3 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -2409,6 +2409,22 @@ void __init cpuset_init_smp(void)
> BUG_ON(!cpuset_migrate_mm_wq);
> }
>
> +/**
> + * cpuset_lock - Grab the cpuset_mutex from another subsysytem
> + */
> +int cpuset_lock(void)
Shouldn't this be called "cpuset_trylock()" otherwise one may think
that it will always return with the cpuset_mutex locked.
-- Steve
> +{
> + return mutex_trylock(&cpuset_mutex);
> +}
> +
> +/**
> + * cpuset_unlock - Release the cpuset_mutex from another subsysytem
> + */
Powered by blists - more mailing lists