Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1215122
| From | Boqun Feng <boqun.feng@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed() |
| Date | 2015-08-28 08:40 +0200 |
| Message-ID | <q2luq-3FD-9@gated-at.bofh.it> (permalink) |
| References | <q2j9g-ps-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
Hi Wanpeng,
On Fri, Aug 28, 2015 at 12:02:47PM +0800, Wanpeng Li wrote:
<snip>
> This patch fix it by following the rules for changing task_struct::cpus_allowed
> w/ both pi_lock and rq->lock are held.
>
> Reported-by: kernel test robot <ying.huang@intel.com>
> Reported-by: Sasha Levin <sasha.levin@oracle.com>
> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
> ---
> v1 -> v2:
> * fix the silly double lock stuff
> * follow the rules for changing task_struct::cpus_allowed
>
> kernel/sched/core.c | 22 ++++++++++++++++++++++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b3386c6..8cf87e3 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5186,6 +5186,27 @@ static void migrate_tasks(struct rq *dead_rq)
> BUG_ON(!next);
> next->sched_class->put_prev_task(rq, next);
>
> + /*
> + * Rules for changing task_struct::cpus_allowed are holding
> + * both pi_lock and rq->lock, such that holding either
> + * stabilizes the mask.
> + *
> + * Drop rq->lock is not quite as disastrous as it usually is
> + * because !cpu_active at this point, which means load-balance
> + * will not interfere.
> + */
> + lockdep_unpin_lock(&rq->lock);
> + raw_spin_unlock(&rq->lock);
> + raw_spin_lock(&next->pi_lock);
> + raw_spin_lock(&rq->lock);
> + lockdep_pin_lock(&rq->lock);
> + if (!(task_rq(next) == rq && task_on_rq_queued(next))) {
> + lockdep_unpin_lock(&rq->lock);
> + raw_spin_unlock(&rq->lock);
Dropping rq->lock here means we will continue the loop without the
rq->lock, right? But we do have a lockdep_pin_lock(&rq->lock) in the
beginning of every iteration. So can we release rq->lock here?
Regards,
Boqun
> + raw_spin_unlock(&next->pi_lock);
> + continue;
> + }
> +
> /* Find suitable destination for @next, with force if needed. */
> dest_cpu = select_fallback_rq(dead_rq->cpu, next);
>
> @@ -5196,6 +5217,7 @@ static void migrate_tasks(struct rq *dead_rq)
> rq = dead_rq;
> raw_spin_lock(&rq->lock);
> }
> + raw_spin_unlock(&next->pi_lock);
> }
>
> rq->stop = stop;
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed() Wanpeng Li <wanpeng.li@hotmail.com> - 2015-08-28 06:10 +0200
Re: [PATCH v2] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed() Boqun Feng <boqun.feng@gmail.com> - 2015-08-28 08:40 +0200
Re: [PATCH v2] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed() Wanpeng Li <wanpeng.li@hotmail.com> - 2015-08-28 08:50 +0200
csiph-web