Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 1 Sep 2022 15:03:11 +0100
From:   Mel Gorman <mgorman@suse.de>
To:     Abel Wu <wuyun.abel@bytedance.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Josh Don <joshdon@google.com>, Chen Yu <yu.c.chen@intel.com>,
        Yicong Yang <yangyicong@huawei.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/5] sched/fair: cleanup for SIS_PROP
Message-ID: <20220901140311.xi3y72uxdwbpxzrq@suse.de>
References: <20220901131107.71785-1-wuyun.abel@bytedance.com>
 <20220901131107.71785-5-wuyun.abel@bytedance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20220901131107.71785-5-wuyun.abel@bytedance.com>
Precedence: bulk

On Thu, Sep 01, 2022 at 09:11:07PM +0800, Abel Wu wrote:
> The sched-domain of this cpu is only used when SIS_PROP is enabled,
> and it should be irrelevant whether the local sd_llc is valid or
> not, since all we care about is target sd_llc if !SIS_PROP.
> 
> Signed-off-by: Abel Wu <wuyun.abel@bytedance.com>

This could conceivably result in an uninitialised memory access if
SIS_PROP was enabled while select_idle_cpu is running. I'm not sure if
it can happen when jump labels are in use but I think it could happen
for !CONFIG_JUMP_LABEL updating the sysctl_sched_features bitmap updated
via sysctl.

The patch is still a good idea because it moves an unlikely rcu_deference
out of the default path for sched features but either this_sd needs to
be initialised to NULL and checked or the this_sd lookup needs to happen
twice at a slight additional cost to the default-disabled SIS_PROP path.

-- 
Mel Gorman
SUSE Labs