Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210422120459.447350175@infradead.org> <20210422123308.196692074@infradead.org>
In-Reply-To: <20210422123308.196692074@infradead.org>
From:   Josh Don <joshdon@google.com>
Date:   Fri, 23 Apr 2021 18:22:52 -0700
Message-ID: <CABk29Ntop2nX+z1bV7giG8ToR_w3f_+GYGAw+hFQ6g9rCZunmw@mail.gmail.com>
Subject: Re: [PATCH 04/19] sched: Prepare for Core-wide rq->lock
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        "Hyser,Chris" <chris.hyser@oracle.com>,
        Ingo Molnar <mingo@kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Mel Gorman <mgorman@suse.de>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Peter,

> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -186,12 +186,37 @@ int sysctl_sched_rt_runtime = 950000;
>
>  void raw_spin_rq_lock_nested(struct rq *rq, int subclass)
>  {
> -       raw_spin_lock_nested(rq_lockp(rq), subclass);
> +       raw_spinlock_t *lock;
> +
> +       if (sched_core_disabled()) {

Nothing to stop sched_core from being enabled right here? Leading to
us potentially taking the wrong lock.

> +               raw_spin_lock_nested(&rq->__lock, subclass);
> +               return;
> +       }
> +
> +       for (;;) {
> +               lock = rq_lockp(rq);
> +               raw_spin_lock_nested(lock, subclass);
> +               if (likely(lock == rq_lockp(rq)))
> +                       return;
> +               raw_spin_unlock(lock);
> +       }
>  }