[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200917143850.25akkvr32ojtwohy@linutronix.de>
Date: Thu, 17 Sep 2020 16:38:50 +0200
From: Sebastian Siewior <bigeasy@...utronix.de>
To: peterz@...radead.org
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Qais Yousef <qais.yousef@....com>,
Scott Wood <swood@...hat.com>,
Valentin Schneider <valentin.schneider@....com>,
Ingo Molnar <mingo@...nel.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Vincent Donnefort <vincent.donnefort@....com>
Subject: Re: [patch 09/10] sched/core: Add migrate_disable/enable()
On 2020-09-17 16:24:38 [+0200], peterz@...radead.org wrote:
> And if I'm not mistaken, the above migrate_enable() *does* require being
> able to schedule, and our favourite piece of futex:
>
> raw_spin_lock_irq(&q.pi_state->pi_mutex.wait_lock);
> spin_unlock(q.lock_ptr);
>
> is broken. Consider that spin_unlock() doing migrate_enable() with a
> pending sched_setaffinity().
There are two instances of the above and only in the futex code and we
have sort of duct tape for that by manually balancing the migrate
counter so that it does not come to this.
But yes, not having to do the manual balance is a plus.
Sebastian
Powered by blists - more mailing lists