From nobody Fri Apr 3 10:24:59 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 D29A83D9035; Tue, 24 Mar 2026 09:10:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774343411; cv=none; b=Z2Bj8gVtc6yf2Yd6dsbTwqXTKPuqodT2quGUDVu1mna/OBuP2nJFQjOHv+VgvrmiwEsMoFtY5mGuatZb3FSCBU/sNJ7+LBFvbhSYrh7TT16qAtdZXO8ptp2osKNG+uOpTHC6h5UftOCtnAkmUjijig/VdXjQBSOwRQO9B2UaGQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774343411; c=relaxed/simple; bh=qQngWLD34+ivQCC5As7zFK1ouMAIlAsgC0jeoArUzXo=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=mWxmSya78BbWVhcau1BALSKsMK2zPsTztlGF1f8DdBNuY+91UP9ROWshxChk+fWbJv2buZrhmTHqyeW1gcBqodhCiIZclc/RfP5Gb5c1XkUh5TKeNi3mQkk+A0qrjXVomAEjjTHgtA+kfxgQ73lMKY+aaPiDD3btYv/C3ckgpyE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Zh+/Ilpm; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Mxpgqe++; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Zh+/Ilpm"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Mxpgqe++" Date: Tue, 24 Mar 2026 09:10:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1774343401; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p1HXsMM7yOOpGDQuTfVWUqcG1gR3Bf10uw4BFEB8Atk=; b=Zh+/Ilpm1ck/WUpF7tz1BMeUPkMophuqy6CRkrup1DDlH6V7G6r2VSZlcQC8TphW6B+tjJ iGmYkMqzJ/Ppemx6H1psCgZ2SBnuH5i1UTWjmn1hmepZYODvmMpGL+NlLQWbhq+rHp43Ad ZPqi7fkVPmk8OoQK2QhoKj3ETWW1/+4dVTcMXeSsMGUkm5rUszkwxrw/FBs3k4TB/NXufT wsB6NBc7A2iUldaNFaxgXD7Ml6qQxivAIf/ZO5pv19NLDqF3clt+czb62VFcTSN0RgWDT7 pF3961ibWhUoCMWt2jjBG71t5xknIYvpm4RG7I40jP7dZBLPg/yD9rqkgYB9cg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1774343401; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p1HXsMM7yOOpGDQuTfVWUqcG1gR3Bf10uw4BFEB8Atk=; b=Mxpgqe++id2IZg98E14tCtLxaT69mNe3S/wbTtmGcX9WNGzRleOWIQZzFFQNBpCJTb79KO c/NdIWiNhKNe+FAQ== From: "tip-bot2 for Peter Zijlstra" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] sched/topology: Fix sched_domain_span() Cc: Nathan Chancellor , "Peter Zijlstra (Intel)" , Jon Hunter , Chen Yu , K Prateek Nayak , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20260323093627.GY3738010@noisy.programming.kicks-ass.net> References: <20260323093627.GY3738010@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <177434340048.1647592.8586759362906719839.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the sched/core branch of tip: Commit-ID: e379dce8af11d8d6040b4348316a499bfd174bfb Gitweb: https://git.kernel.org/tip/e379dce8af11d8d6040b4348316a499bf= d174bfb Author: Peter Zijlstra AuthorDate: Mon, 23 Mar 2026 10:36:27 +01:00 Committer: Peter Zijlstra CommitterDate: Tue, 24 Mar 2026 10:07:04 +01:00 sched/topology: Fix sched_domain_span() Commit 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset partitions") ends up relying on the fact that structure initialization should not touch the flexible array. However, the official GCC specification for "Arrays of Length Zero" [*] 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. Additionally, structure initialization will zero tail padding. With the end result that since offsetof(*type, member) < sizeof(*type), array initialization will clobber the flex array. Luckily, the way flexible array sizes are calculated is: sizeof(*type) + count * sizeof(*type->member) This means we have the complete size of the flex array *outside* of sizeof(*type), so use that instead of relying on the broken flex array definition. [*] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Fixes: 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset = partitions") Reported-by: Nathan Chancellor Debugged-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Tested-by: Jon Hunter Tested-by: Chen Yu Tested-by: K Prateek Nayak Tested-by: Nathan Chancellor Link: https://patch.msgid.link/20260323093627.GY3738010@noisy.programming.k= icks-ass.net --- include/linux/sched/topology.h | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h index 51c2958..36553e1 100644 --- a/include/linux/sched/topology.h +++ b/include/linux/sched/topology.h @@ -142,18 +142,30 @@ struct sched_domain { =20 unsigned int span_weight; /* - * Span of all CPUs in this domain. + * See sched_domain_span(), on why flex arrays are broken. * - * NOTE: this field is variable length. (Allocated dynamically - * by attaching extra space to the end of the structure, - * depending on how many CPUs the kernel has booted up with) - */ unsigned long span[]; + */ }; =20 static inline struct cpumask *sched_domain_span(struct sched_domain *sd) { - return to_cpumask(sd->span); + /* + * Turns out that C flexible arrays are fundamentally broken since it + * is allowed for offsetof(*sd, span) < sizeof(*sd), this means that + * structure initialzation *sd =3D { ... }; which writes every byte + * inside sizeof(*type), will over-write the start of the flexible + * array. + * + * Luckily, the way we allocate sched_domain is by: + * + * sizeof(*sd) + cpumask_size() + * + * this means that we have sufficient space for the whole flex array + * *outside* of sizeof(*sd). So use that, and avoid using sd->span. + */ + unsigned long *bitmap =3D (void *)sd + sizeof(*sd); + return to_cpumask(bitmap); } =20 extern void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[= ],