Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3950281ybg; Fri, 25 Oct 2019 11:10:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqyXjMIPhwBMq+3Twh0ynYkEdncYrw4byinaZ1seI0WawnAn0ObLhknD4MhMOBjH+zbpnQrz X-Received: by 2002:a50:da0f:: with SMTP id z15mr5483064edj.137.1572027018773; Fri, 25 Oct 2019 11:10:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572027018; cv=none; d=google.com; s=arc-20160816; b=oK7Ocb1M42sBe7PYUJjossyGSi1jJIcprhtE3Rksyg8oZ/jS7GbWWu57bYiJvlpgEB 6vVF02/BgBWLclkibtd6uLtKdjttZJhDMt2P/JHCf4wuKCwG6hVoICTAXMF3hP3R5hS/ 4tXUpXmJOy/2b7hTjh++HCHpfukp5vhKRH21LHH7sHUweMz8pg6+qolbjLdHO5Z2s7Q/ erLISOBqcYrVRkCw04EhnB2zOsLRGV4v99WgyNZJL76a3OQXfaiEv/Dn3QyJ96Rs2t9f kKzGBsayKWiG8n5/oEXQVUl8ZjFzhJisD/2Krq03wc5JOabUMj9LNJMQpJmKHudZP2P2 1j0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=lAA5zPGt+Rzi74P1R4CA5LoL8r/OPAgkNKtbMUS+Xx8=; b=qE0WkrOuVFwllCuZc92B7ghPYKwoJ949HaQj61yIXdjwc9Rib0g93TepiTmByShXg/ 2PG+g5R81WNgGKY+be/ddkt3J5FI2MSsKldSouxi7Pt3vIvOSnwKgUcyg1cjUVxsu+Zu pK0dKtsQrhQMnvdG091/8+s3AAaeQeNwjqFT0hOthky7YBYGsnASJDJQBlEXCK3wcEVV GZYdZwR4gIPzO+/LSJX1y7Sq/M/WCQ0fPPDJOldvQr4NLnJ0QWP2lAyShlCBZ2lVSr7B 7lUx1P1dZZlVvHnPH50vUfm7M9+F+aeSszXuVy5+VG4q1kTRQSzKsoIWIQG4b2ycwtCS O1+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w30si1771717edd.137.2019.10.25.11.09.55; Fri, 25 Oct 2019 11:10:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439790AbfJXQUF (ORCPT + 99 others); Thu, 24 Oct 2019 12:20:05 -0400 Received: from foss.arm.com ([217.140.110.172]:55716 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436636AbfJXQUF (ORCPT ); Thu, 24 Oct 2019 12:20:05 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5D7F7328; Thu, 24 Oct 2019 09:19:49 -0700 (PDT) Received: from [192.168.0.9] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E9AC3F71F; Thu, 24 Oct 2019 09:19:47 -0700 (PDT) Subject: Re: [PATCH v4 1/2] sched/topology: Don't try to build empty sched domains To: Valentin Schneider , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Cc: lizefan@huawei.com, tj@kernel.org, hannes@cmpxchg.org, mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, morten.rasmussen@arm.com, qperret@google.com, stable@vger.kernel.org References: <20191023153745.19515-1-valentin.schneider@arm.com> <20191023153745.19515-2-valentin.schneider@arm.com> From: Dietmar Eggemann Message-ID: <27d8a51d-a899-67f4-8b74-224281f25cef@arm.com> Date: Thu, 24 Oct 2019 18:19:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191023153745.19515-2-valentin.schneider@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/10/2019 17:37, Valentin Schneider wrote: > Turns out hotplugging CPUs that are in exclusive cpusets can lead to the > cpuset code feeding empty cpumasks to the sched domain rebuild machinery. > This leads to the following splat: [...] > The faulty line in question is > > cap = arch_scale_cpu_capacity(cpumask_first(cpu_map)); > > and we're not checking the return value against nr_cpu_ids (we shouldn't > have to!), which leads to the above. > > Prevent generate_sched_domains() from returning empty cpumasks, and add > some assertion in build_sched_domains() to scream bloody murder if it > happens again. > > The above splat was obtained on my Juno r0 with: > > cgcreate -g cpuset:asym > cgset -r cpuset.cpus=0-3 asym > cgset -r cpuset.mems=0 asym > cgset -r cpuset.cpu_exclusive=1 asym > > cgcreate -g cpuset:smp > cgset -r cpuset.cpus=4-5 smp > cgset -r cpuset.mems=0 smp > cgset -r cpuset.cpu_exclusive=1 smp > > cgset -r cpuset.sched_load_balance=0 . > > echo 0 > /sys/devices/system/cpu/cpu4/online > echo 0 > /sys/devices/system/cpu/cpu5/online > > Cc: > Fixes: 05484e098448 ("sched/topology: Add SD_ASYM_CPUCAPACITY flag detection") Sorry for being picky but IMHO you should also mention that it fixes f9a25f776d78 ("cpusets: Rebuild root domain deadline accounting information") Tested it on a hikey620 (8 CPus SMP) with v5.4-rc4 and a local fix for asym_cpu_capacity_level(). 2 exclusive cpusets [0-3] and [4-7], hp'ing out [0-3] and then hp'ing in [0] again. diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 5a174ae6ecf3..8f83e8e3ea9a 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -2203,8 +2203,19 @@ void partition_sched_domains_locked(int ndoms_new, cpumask_var_t doms_new[], for (i = 0; i < ndoms_cur; i++) { for (j = 0; j < n && !new_topology; j++) { if (cpumask_equal(doms_cur[i], doms_new[j]) && - dattrs_equal(dattr_cur, i, dattr_new, j)) + dattrs_equal(dattr_cur, i, dattr_new, j)) { + struct root_domain *rd; + + /* + * This domain won't be destroyed and as such + * its dl_bw->total_bw needs to be cleared. It + * will be recomputed in function + * update_tasks_root_domain(). + */ + rd = cpu_rq(cpumask_any(doms_cur[i]))->rd; We have an issue here if doms_cur[i] is empty. + dl_clear_root_domain(rd); goto match1; There is yet another similar issue behind the first one (asym_cpu_capacity_level()). 342 static bool build_perf_domains(const struct cpumask *cpu_map) 343 { 344 int i, nr_pd = 0, nr_cs = 0, nr_cpus = cpumask_weight(cpu_map); 345 struct perf_domain *pd = NULL, *tmp; 346 int cpu = cpumask_first(cpu_map); <--- !!! 347 struct root_domain *rd = cpu_rq(cpu)->rd; <--- !!! 348 struct cpufreq_policy *policy; 349 struct cpufreq_governor *gov; ... 406 tmp = rd->pd; <--- !!! Caught when running hikey620 (8 CPus SMP) with v5.4-rc4 and a local fix for asym_cpu_capacity_level() with CONFIG_ENERGY_MODEL=y. There might be other places in build_sched_domains() suffering from the same issue. So I assume it's wise to not call it with an empty cpu_map and warn if done so. [...]