From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 9F04E27AC48 for ; Mon, 23 Mar 2026 09:36:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774258607; cv=none; b=WFQuemkglrbGkB8+ayDSaKCyyCqoqewBGtvniMm8+WWDkb6fFqAHQcImb1odEB3uQO13JThjHepxPnl23DyeDBwfL7s416iHEExS74oLWOCvLgSJQBF2kpODbnr4WRF/pklXtO5G+m0YTbymsWcisoQ6Rm23soldQxwkzZ/PadQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774258607; c=relaxed/simple; bh=yWsdmmMK1OwAeE8f9fKIL8DyWn8L9NAYi6UIIHSqj5s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WaouMFyMuUypVW7BWP8bqWARszageBL3glKqPnpsH0IGLqoLAyLib/IQdNoqDvRh6c2iuJSCmiQ6njNgEXs0LgJnYVhLvQnB43TtqAmiCiU13Q9BsoxncPO9sFREAEm1/xsvFokB0R/pEIf+t/ceTqrMtfSmR9wFZDsQyFd/VbY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=aDpooq+l; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="aDpooq+l" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=R5MV5jYJaaX8eEAnpXOaCldr12gQH8jprwV2NolXDCI=; b=aDpooq+lV6PbiSaazECZ4awlMp 0hYHi0kwfvPHgEkV9B2nmzs0CCsgg6zcgck70ZJwX+p9B6zNUglB7x5J5G4IBYkFF+FklKe+7Cbrt CqCDJGJN8GSjszZk4a941RbLjm4KEzJ43167HGli/laVKphKRmV5WNch8aGG9dlixGWHmjfsML5Ei /cMNz4nNASMp76X0b3Dmd4uPlTHuYy9eWQvuoEwM0MumoFX3A+uPfkYw07qYGA9mwSyk47Y9TRJmM IxSz88Mtf+P4FCce3o3ZManYAPKVKZZwk5gfgB6aJx1HpMPRmZVPDANsC2KvTVMIaetLLIftchaU+ jEBCCHxQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w4bi0-0000000BxYf-3WLM; Mon, 23 Mar 2026 09:36:29 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id BC30E300346; Mon, 23 Mar 2026 10:36:27 +0100 (CET) Date: Mon, 23 Mar 2026 10:36:27 +0100 From: Peter Zijlstra To: K Prateek Nayak Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Nathan Chancellor , Valentin Schneider , Dietmar Eggemann , Shrikanth Hegde , Chen Yu , linux-kernel@vger.kernel.org, Steven Rostedt , Ben Segall , Mel Gorman , "Gautham R. Shenoy" , x86@kernel.org, Kees Cook Subject: Re: [PATCH] sched/topology: Initialize sd_span after assignment to *sd Message-ID: <20260323093627.GY3738010@noisy.programming.kicks-ass.net> References: <20260320235824.GA1176840@ax162> <20260321163852.11102-1-kprateek.nayak@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260321163852.11102-1-kprateek.nayak@amd.com> On Sat, Mar 21, 2026 at 04:38:52PM +0000, 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. WTF! that's terrible :( Why is this allowed, this makes no bloody sense :/ However the way we allocate space for flex arrays is: sizeof(*obj) + count * sizeof(*obj->member); this means that we do have sufficient space, irrespective of this extra padding. Does this work? diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h index 51c29581f15e..defa86ed9b06 100644 --- a/include/linux/sched/topology.h +++ b/include/linux/sched/topology.h @@ -153,7 +153,21 @@ struct sched_domain { static inline struct cpumask *sched_domain_span(struct sched_domain *sd) { - return to_cpumask(sd->span); + /* + * Because C is an absolutely broken piece of shit, it is allowed for + * offsetof(*sd, span) < sizeof(*sd), this means that structure + * initialzation *sd = { ... }; which will clear every unmentioned + * member, can over-write the start of the flexible array member. + * + * Luckily, the way we allocate the flexible array is by: + * + * sizeof(*sd) + count * sizeof(*sd->span) + * + * 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 = (void *)sd + sizeof(*sd); + return to_cpumask(bitmap); } extern void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],