From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5CD4336EE7 for ; Mon, 23 Mar 2026 09:09:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774256966; cv=none; b=ANBGT0o5E3yRffNaksxc576HdROer8MxGajp7biLypfDVS33xnN2lj79a1mgdKMkffzVmFHctdXziGk7/Zm/WbMKtuYw8mlM+PwhEnbFBtlmfnWM0tZhTwAKe3hSiGwGcB07+wjtDv1JG1n6X+XfPofle7Q4PB7kQB/+eWm/VY0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774256966; c=relaxed/simple; bh=4x4wpT8NeBI6mxNhoyzrnYi8gkCVGEOiCYbJJAClEM4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Gl3TGyKziuqwJRLOfMN5b96M9avrN6YDy0eYnRLQ/yAcn3vr4UMSijqUy9sRpghJkzweWRPXaIwc3wb99dzvlBfq33gDpx07keqdOhv1jjCiFVN4wteMGsCqq5OvLkCRmADTo07DRvHou1t4qLiCfpZgy+JMHsHSkzoUS7n2ors= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=HFSQRzzx; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="HFSQRzzx" Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62MBQdEn3792418; Mon, 23 Mar 2026 09:09:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=h7X91i jjDP6iDFDGizxNEksA5KtTHg4YtOZ5crB4HBo=; b=HFSQRzzxezESxbJYnL/+mK zptWG4Pk+XDAzhZJevmfzkUDjXScn5PyjBBP2CWs6QiSFRkLO6SsyvJHMB1//rrT BtrEzsGKwICB7gPePhastgktdeLMhN1fMyeLldiVdAt1oQ8fanMeBgvBci/T4VvW xgR59uo/szyV8lVmCuUzvtKH5DIH0L41BC4vDC/R5yZgZD6VPoPr9XIMl4yO46Cx y0tIEna0gRogE+n16H2FrCjEuwVtUG3+0kWTmc0hbXpLitm3909K9/VAuX1VGNFb 1HY9u7Jj42bu6dNidWVc0w7LlV5Zgz5TvcV6gYJ7OqYA3TRWhIZ+T+9cglg4/INA == Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4d1kxq64e7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2026 09:09:00 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 62N83p9C011778; Mon, 23 Mar 2026 09:08:59 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4d27vjvhmg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2026 09:08:59 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 62N98wBx42533214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Mar 2026 09:08:58 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 023792004E; Mon, 23 Mar 2026 09:08:58 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2BF1520043; Mon, 23 Mar 2026 09:08:55 +0000 (GMT) Received: from [9.123.5.233] (unknown [9.123.5.233]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 23 Mar 2026 09:08:54 +0000 (GMT) Message-ID: <2c5e1ed7-cd7c-49e3-8cb0-ebe7365ba315@linux.ibm.com> Date: Mon, 23 Mar 2026 14:38:53 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sched/topology: Initialize sd_span after assignment to *sd To: K Prateek Nayak Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Nathan Chancellor , Valentin Schneider , Dietmar Eggemann , Chen Yu , linux-kernel@vger.kernel.org, Steven Rostedt , Ben Segall , Mel Gorman , "Gautham R. Shenoy" , x86@kernel.org References: <20260320235824.GA1176840@ax162> <20260321163852.11102-1-kprateek.nayak@amd.com> From: Shrikanth Hegde Content-Language: en-US In-Reply-To: <20260321163852.11102-1-kprateek.nayak@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-ORIG-GUID: GbIU1xbypVu9ZmMeswhRbiUhvG82QNzS X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzIzMDA2NyBTYWx0ZWRfX2qBZnlqYzzD3 QlSTyVDZujzzQifH9pR4bFxKGU0wVWtyXkEP+COVNes3emZdWRWVSKz1pOZJ1YAf9ZzQAEkAHjE 1KBa9MHauwsTGGVVyjJ0QBLT/OSOP/1xVtVayfnrYanwb5jMSZPyTg2L30mDrLsTAmhXDs4le/3 4FeC8BywoWHvfnyGlSwAukB0a9Z+4MByrbO92xBMTUHd7eUEVVDOmr9dBd4T6xhejHnSQKvecSf 6rxm0WQsEpMH1j5jCuVDR5DKeLvKYn1G13KdXVc2cVY/adICatKBMdDk5SR8o67yJsAcd3Vf4ED 5ffhbAu9RV26BGsYSu1JuPpQZdByf8e+F5k4/DpTmJtAoEhYCp9Yu7vYyjOtzIjauvExa0hSOi4 FfOZ5HxutzJVacf5vbWpLBDoRNsAq+7bwfbg2ClpR5G7U+CUib7vAlPVKl8Q/v8Ignkae8Db+NC NCtlFdmdl4U93DaywAw== X-Authority-Analysis: v=2.4 cv=bLEb4f+Z c=1 sm=1 tr=0 ts=69c1032d cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=VwQbUJbxAAAA:8 a=zd2uoN0lAAAA:8 a=mDV3o1hIAAAA:8 a=VnNF1IyMAAAA:8 a=qDSw8c5wzDgv-jC-EOoA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: e-UhSCU5vfle_7Aui1iI_u0wiciCCi9q X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-23_02,2026-03-20_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 clxscore=1015 phishscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603230067 On 3/21/26 10:08 PM, K Prateek Nayak wrote: > Nathan reported a kernel panic on his ARM builds after commit > 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset > partitions") which was root caused to the compiler zeroing out the first > few bytes of sd->span. > > During the debug [1], it was discovered that, on some configs, > offsetof(struct sched_domain, span) at 292 was less than > sizeof(struct sched_domain) at 296 resulting in: > > *sd = { ... } > > assignment clearing out first 4 bytes of sd->span which was initialized > before. > > The official GCC specification for "Arrays of Length Zero" [2] says: > > Although the size of a zero-length array is zero, an array member of > this kind may increase the size of the enclosing type as a result of > tail padding. > > which means the relative offset of the variable length array at the end > of the sturct can indeed be less than sizeof() the struct as a result of > tail padding thus overwriting that data of the flexible array that > overlapped with the padding whenever the struct is initialized as whole. > > Partially revert commit 8e8e23dea43e ("sched/topology: Compute sd_weight > considering cpuset partitions") to initialize sd_span after the fixed > memebers of sd. > > Use > > cpumask_weight_and(cpu_map, tl->mask(tl, cpu)) > > to calculate span_weight before initializing the sd_span. > cpumask_and_weight() is of same complexity as cpumask_and() and the > additional overhead is negligible. > > While at it, also initialize sd->span_weight in sd_init() since > sd_weight now captures the cpu_map constraints. Fixup the > sd->span_weight whenever sd_span is fixed up by the generic topology > layer. > This description is a bit confusing. Fixup happens naturally since cpu_map now reflects the changes right? Maybe mention about that removal in build_sched_domains? > Reported-by: Nathan Chancellor > Closes: https://lore.kernel.org/all/20260320235824.GA1176840@ax162/ > Fixes: 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset partitions") > Link: https://lore.kernel.org/all/a8c125fd-960d-4b35-b640-95a33584eb08@amd.com/ [1] > Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] > Signed-off-by: K Prateek Nayak > --- > Nathan, can you please check if this fixes the issue you are observing - > it at least fixed one that I'm observing ;-) > > Peter, if you would like to keep revert and enhancements separate, let > me know and I'll spin a v2. > --- > kernel/sched/topology.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index 43150591914b..721ed9b883b8 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -1669,17 +1669,13 @@ sd_init(struct sched_domain_topology_level *tl, > struct cpumask *sd_span; > u64 now = sched_clock(); > > - sd_span = sched_domain_span(sd); > - cpumask_and(sd_span, cpu_map, tl->mask(tl, cpu)); > - sd_weight = cpumask_weight(sd_span); > - sd_id = cpumask_first(sd_span); > + sd_weight = cpumask_weight_and(cpu_map, tl->mask(tl, cpu)); > > if (tl->sd_flags) > sd_flags = (*tl->sd_flags)(); > if (WARN_ONCE(sd_flags & ~TOPOLOGY_SD_FLAGS, > "wrong sd_flags in topology description\n")) > sd_flags &= TOPOLOGY_SD_FLAGS; > - sd_flags |= asym_cpu_capacity_classify(sd_span, cpu_map); > > *sd = (struct sched_domain){ > .min_interval = sd_weight, > @@ -1715,8 +1711,15 @@ sd_init(struct sched_domain_topology_level *tl, > .last_decay_max_lb_cost = jiffies, > .child = child, > .name = tl->name, > + .span_weight = sd_weight, > }; > > + sd_span = sched_domain_span(sd); > + cpumask_and(sd_span, cpu_map, tl->mask(tl, cpu)); > + sd_id = cpumask_first(sd_span); > + > + sd->flags |= asym_cpu_capacity_classify(sd_span, cpu_map); > + > WARN_ONCE((sd->flags & (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY)) == > (SD_SHARE_CPUCAPACITY | SD_ASYM_CPUCAPACITY), > "CPU capacity asymmetry not supported on SMT\n"); > @@ -2518,6 +2521,8 @@ static struct sched_domain *build_sched_domain(struct sched_domain_topology_leve > cpumask_or(sched_domain_span(sd), > sched_domain_span(sd), > sched_domain_span(child)); > + > + sd->span_weight = cpumask_weight(sched_domain_span(sd)); > } > > } > @@ -2697,7 +2702,6 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att > /* Build the groups for the domains */ > for_each_cpu(i, cpu_map) { > for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) { > - sd->span_weight = cpumask_weight(sched_domain_span(sd)); > if (sd->flags & SD_NUMA) { > if (build_overlap_sched_groups(sd, i)) > goto error; > > base-commit: fe7171d0d5dfbe189e41db99580ebacafc3c09ce Other than nits in changelog: Reviewed-by: Shrikanth Hegde PS: b4 am -Q was quite confused which patch to pick for 0001. may since it was a reply to the thread. Not sure. So i pulled each patch separate and applied.