[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200924122934.GI2628@hirez.programming.kicks-ass.net>
Date: Thu, 24 Sep 2020 14:29:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Valentin Schneider <valentin.schneider@....com>
Cc: tglx@...utronix.de, mingo@...nel.org, linux-kernel@...r.kernel.org,
bigeasy@...utronix.de, qais.yousef@....com, swood@...hat.com,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, bristot@...hat.com, vincent.donnefort@....com
Subject: Re: [PATCH 7/9] sched: Add migrate_disable()
On Thu, Sep 24, 2020 at 12:53:25PM +0100, Valentin Schneider wrote:
> On 21/09/20 17:36, Peter Zijlstra wrote:
>
> [...]
>
> > +void migrate_enable(void)
> > +{
> > + if (--current->migration_disabled)
> > + return;
> > +
> > + barrier();
> > +
> > + if (p->cpus_ptr == &p->cpus_mask)
> > + return;
>
> If we get to here this means we're the migrate_enable() invocation that
> marks the end of the migration_disabled region. How can cpus_ptr already
> point back to current's cpus_mask?
It might never have been changed away.
migrate_disable()
->migration_disabled++;
| |
| |
| v
| migrate_disable_switch()
| if (->cpus_ptr == &->cpus_mask)
| __do_set_cpus_allowed(.new_mask = cpumask_of())
| |
| |
v v
migrate_enable()
->migration_disabled--;
Only if we've passed through a context switch between migrate_disable()
and migrate_enable() will the mask have been changed.
Powered by blists - more mailing lists