From nobody Sat Feb 7 22:07:14 2026 Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (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 721AF255E26; Tue, 7 Oct 2025 23:50:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881042; cv=none; b=HqVBFkbGRyVrm8bGQnjCIRdyv0Br+EYAwfeBcRzQU0C+nX+XsZmOHVuEfNG2Y4wZDc6oXizmOZ+WB6qxnFFXFnLkvVuoB2oaZXowwUh0SgAJ+UXI8MXdhTdKYHS32Qsn2BR9m7KUgt5y0ArG3/H2veVF+Plpugcf83KdeLoA8lg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881042; c=relaxed/simple; bh=o9lkQbbpBibFWvTNPnvl9IY8JEMBKOvXU3P9W52BYN8=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=p3LqmQvzUCcxAtnItPaRefd31FttJoq9IiQtPWvcsUItKU4HsIFbVGVukx7Aj50qxQH4wCVY3I+GlCAggKepqluG21CvPhnSbtNa+cdyIqKSqSg6KEmxYkKsC3EYDu63/9JcbigaC9drMw3l6vbS0jAa4Ck9GA7fSKtpEo1iSEw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=none smtp.mailfrom=linux-m68k.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=ABj6y186; arc=none smtp.client-ip=202.12.124.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ABj6y186" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.stl.internal (Postfix) with ESMTP id 5C8B01D00112; Tue, 7 Oct 2025 19:50:39 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 07 Oct 2025 19:50:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1759881039; x= 1759967439; bh=deVHNxmHpB/t+ufTPYero2jLsQQUFKf8oNfpE3SPyRM=; b=A Bj6y186vePPkbC31PDNQ+ZMcws/90bwULxcYHVuM0LMT2wFqZkFx2jrJk+kAgboo 3Gfo9YWdBlT02aLCAx0ViCacdpdrpV/Zx3fIAyge/5kCx2RtuR5sMj9jD4RCB9CV ksAFY4cpbSZ4ek4+2lfepVj1MfzTbfcDrEggNUKBhM3zeHh5B8BlWcVfLPdu4jRV wq3bh1ilU7Ao5VFmT8KBtFZZeycnaXPRIW1uRiQepwxGS5dB+wWSF+WR8HBzk1kZ JjOe+q9uToejANPrXzuLP8lictMgrw8cXfrw+q09dJYGbGAZCXVHOponELLU78gY 9KfL8140vouhvAwHKLUJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddutddujeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeevgffgtdfhhfefveeuudfgtdeugfeftedtveekieeggfduleetgeegueehgeffffen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfthhhrg hinheslhhinhhugidqmheikehkrdhorhhgpdhnsggprhgtphhtthhopeduvddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorh hgpdhrtghpthhtohepfihilhhlsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrkhhp mheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepsghoqhhunh drfhgvnhhgsehgmhgrihhlrdgtohhmpdhrtghpthhtoheptghorhgsvghtsehlfihnrdhn vghtpdhrtghpthhtohepmhgrrhhkrdhruhhtlhgrnhgusegrrhhmrdgtohhmpdhrtghpth htoheprghrnhgusegrrhhnuggsrdguvgdprhgtphhtthhopehlihhnuhigqdhkvghrnhgv lhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdgrrhgthh esvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Oct 2025 19:50:36 -0400 (EDT) To: Peter Zijlstra , Will Deacon Cc: Andrew Morton , Boqun Feng , Jonathan Corbet , Mark Rutland , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Geert Uytterhoeven , linux-m68k@vger.kernel.org, linux-doc@vger.kernel.org Message-ID: <76571a0e5ed7716701650ec80b7a0cd1cf07fde6.1759875560.git.fthain@linux-m68k.org> In-Reply-To: References: From: Finn Thain Subject: [RFC v3 1/5] documentation: Discourage alignment assumptions Date: Wed, 08 Oct 2025 09:19:20 +1100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Discourage assumptions that simply don't hold for all Linux ABIs. Exceptions to the natural alignment rule for scalar types include long long on i386 and sh. --- Documentation/core-api/unaligned-memory-access.rst | 7 ------- 1 file changed, 7 deletions(-) diff --git a/Documentation/core-api/unaligned-memory-access.rst b/Documenta= tion/core-api/unaligned-memory-access.rst index 5ceeb80eb539..1390ce2b7291 100644 --- a/Documentation/core-api/unaligned-memory-access.rst +++ b/Documentation/core-api/unaligned-memory-access.rst @@ -40,9 +40,6 @@ The rule mentioned above forms what we refer to as natura= l alignment: When accessing N bytes of memory, the base memory address must be evenly divisible by N, i.e. addr % N =3D=3D 0. =20 -When writing code, assume the target architecture has natural alignment -requirements. - In reality, only a few architectures require natural alignment on all sizes of memory access. However, we must consider ALL supported architectures; writing code that satisfies natural alignment requirements is the easiest = way @@ -103,10 +100,6 @@ Therefore, for standard structure types you can always= rely on the compiler to pad structures so that accesses to fields are suitably aligned (assuming you do not cast the field to a type of different length). =20 -Similarly, you can also rely on the compiler to align variables and functi= on -parameters to a naturally aligned scheme, based on the size of the type of -the variable. - At this point, it should be clear that accessing a single byte (u8 or char) will never cause an unaligned access, because all memory addresses are eve= nly divisible by one. --=20 2.49.1 From nobody Sat Feb 7 22:07:14 2026 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 B0876248176; Tue, 7 Oct 2025 23:50:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.159 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881059; cv=none; b=ONzdvhofxC/2k+B/Gp1yk0kkCTLRpLdIef+hYcKIQlif+WxQFqNyy5DmaWB/WRCb36o+v+Rg3uaJM0vdpu0YDt2SKs9nAe2Ffw2sEkE4yxkkGJJK35i3V7QKhkTQVQ1ykLAaVZfQBpfcxseaaFe7LHie+77i87XZy6vfYfnlHAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881059; c=relaxed/simple; bh=rftrhfEKfapeHxVgZj6mK1Ft6S55T/bo4rn2OTQignY=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=SfmULJrpDJrIk14TICmN/QTdomkWLw7UZcQQyTETBiMgvwhO152gC63Bfd9Dw3KG4YDE7f6cKbWRnsUJJVfLgo5iCaCJRNDfSZeWfa6KGGSoVK2Kx+sCU6wD+Ira/J+1fRZA6piLwTP0OnDpJd1vPoeJQtRlQIDw1XGv+/DU+08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=none smtp.mailfrom=linux-m68k.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=pJp0OnNO; arc=none smtp.client-ip=202.12.124.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="pJp0OnNO" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id 63C427A0195; Tue, 7 Oct 2025 19:50:56 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 07 Oct 2025 19:50:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1759881056; x= 1759967456; bh=4/txBbaCQdAI1HAyCzg1zorpr3/M/73CrArjyktCXZU=; b=p Jp0OnNODYtgpPt0sHEvxgkDuQTWwktZg3Y3nOMb378CZkTq1UeLBqWFcTF7Ct8u4 a1n7jeYh+1UIGfTc6AM3IIPJyR7jDorwx69+qWnVf6E2MuhVPAwjH7vW3KvLcTbA E1J7tlHyuRQQf7DgGZ1MDlbYkQ3SCpBebtJ3mOmjjZlUJdKyXbj9EIyhQUzjbtwc 5sVa9GvG1NPCG1bSxyWP4AtFoys+O0dx5dFtTprPbXXOTojs9ydOd3QVQ0+N2epN bnpURsQNzrvmUGLssBCAh90ArOzuzxXX7I5XGVSBdEOANOZc5WGGwOwAXLiXuqJA MNDqKWJA6NpOCJXvYHgSg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddutddujeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeevgffgtdfhhfefveeuudfgtdeugfeftedtveekieeggfduleetgeegueehgeffffen ucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehfthhhrg hinheslhhinhhugidqmheikehkrdhorhhgpdhnsggprhgtphhtthhopedvgedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorh hgpdhrtghpthhtohepfihilhhlsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrshht sehkvghrnhgvlhdrohhrghdprhgtphhtthhopegurghnihgvlhesihhoghgvrghrsghogi drnhgvthdprhgtphhtthhopegrnhgurhhiiheskhgvrhhnvghlrdhorhhgpdhrtghpthht oheprghkphhmsehlihhnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhope gsohhquhhnrdhfvghnghesghhmrghilhdrtghomhdprhgtphhtthhopegtohhrsggvthes lhifnhdrnhgvthdprhgtphhtthhopehmrghrkhdrrhhuthhlrghnugesrghrmhdrtghomh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Oct 2025 19:50:52 -0400 (EDT) To: Peter Zijlstra , Will Deacon , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: Andrew Morton , Boqun Feng , Jonathan Corbet , Mark Rutland , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Geert Uytterhoeven , linux-m68k@vger.kernel.org, Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , bpf@vger.kernel.org Message-ID: <807cfee43bbcb34cdc6452b083ccdc754344d624.1759875560.git.fthain@linux-m68k.org> In-Reply-To: References: From: Finn Thain Subject: [RFC v3 2/5] bpf: Explicitly align bpf_res_spin_lock Date: Wed, 08 Oct 2025 09:19:20 +1100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Align bpf_res_spin_lock to avoid a BUILD_BUG_ON() when the alignment changes, as it will do on m68k when, in a subsequent patch, the minimum alignment of the atomic_t member of struct rqspinlock gets increased. Drop the BUILD_BUG_ON() as it is now redundant. Cc: Martin KaFai Lau Cc: Eduard Zingerman Cc: Song Liu Cc: Yonghong Song Cc: John Fastabend Cc: KP Singh Cc: Stanislav Fomichev Cc: Hao Luo Cc: Jiri Olsa --- include/asm-generic/rqspinlock.h | 2 +- kernel/bpf/rqspinlock.c | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/include/asm-generic/rqspinlock.h b/include/asm-generic/rqspinl= ock.h index 6d4244d643df..eac2dcd31b83 100644 --- a/include/asm-generic/rqspinlock.h +++ b/include/asm-generic/rqspinlock.h @@ -28,7 +28,7 @@ struct rqspinlock { */ struct bpf_res_spin_lock { u32 val; -}; +} __aligned(__alignof__(struct rqspinlock)); =20 struct qspinlock; #ifdef CONFIG_QUEUED_SPINLOCKS diff --git a/kernel/bpf/rqspinlock.c b/kernel/bpf/rqspinlock.c index 338305c8852c..a88a0e9749d7 100644 --- a/kernel/bpf/rqspinlock.c +++ b/kernel/bpf/rqspinlock.c @@ -671,7 +671,6 @@ __bpf_kfunc int bpf_res_spin_lock(struct bpf_res_spin_l= ock *lock) int ret; =20 BUILD_BUG_ON(sizeof(rqspinlock_t) !=3D sizeof(struct bpf_res_spin_lock)); - BUILD_BUG_ON(__alignof__(rqspinlock_t) !=3D __alignof__(struct bpf_res_sp= in_lock)); =20 preempt_disable(); ret =3D res_spin_lock((rqspinlock_t *)lock); --=20 2.49.1 From nobody Sat Feb 7 22:07:14 2026 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 4611723E35B; Tue, 7 Oct 2025 23:51:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.159 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881070; cv=none; b=E7/dk/bIa7payIQtOrHiA9ZGrKMIp7V+xXpHwqbn5Y6d7vAdWkzFyWOylWCEmuSLVNeMXkj9sW/XhnLh0XIC2p5yYln9UcddbG98t7HRtOH/wLXuhkkLTMZJVAqYHs0FI0NcTTCFzm1/wd5FnUVqIQ7AaNCvsF6dCG1Qyqhxed8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881070; c=relaxed/simple; bh=4QyH1EVYZrIL8ROTUcvFrBkVfvsFyB/Ot/CJkrr+16A=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=b17daFuBxgdn2HiGdVoaB4i2Ty+F8fTpNbsG6AOb9xl2eQ7V45Nd0qtYablei9Q9OpTWEGxebJFrkCVAyu19FJ1Dtb7/e9n5grdZnx5aULnPVk1nUGVKw0R+PmXkps1rgSVQDn9RV29JvnV9NfOsAoQKtYyqxOrEHjFda3kC3yU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=none smtp.mailfrom=linux-m68k.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=xVzri3LJ; arc=none smtp.client-ip=202.12.124.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="xVzri3LJ" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 70AFA7A0053; Tue, 7 Oct 2025 19:51:08 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 07 Oct 2025 19:51:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1759881068; x= 1759967468; bh=nbJ+bkF+lRtSSBYxfQH9cNkhYr225g6snGXYRYj7rYk=; b=x Vzri3LJEagBBhGyxDdDzdCB7NOmuy8eAXDl7JuKG26rL7TbMLa30iAOo7aOxhWuQ I4HdMj7HDaeBOrbczXzqlezVKj1yTg+AdKAVuCxEKHiIcjV3EkUdxmQKX1ehkxg0 69RcN/wR3Ga886L1xV+3dcy+a1P+/tl9bhQQ77tKVwT3ZTkcxbfL2iK6oAiubggH 8ui4jF5KGjPQXcGgt4sMjKvYdwifuRM1vEJmUk+cGkyU9T/1Ra8ne1Nrk2hV0+UA txmioGDFYKzMm2nWLj255zlfy1bFV3GMoayhRZsn9r3SlAgcQBFGw88BPbhOW9xe ZHTbs85e+i3+tgiXWNHvQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddutddujeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeehkeduffehjedvieevkeelleegffeiuddvgeeluefhuedugeekkeehffekgffgheen ucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepfhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhr ghdpnhgspghrtghpthhtohepuddvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhope hpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopeifihhllheskhgv rhhnvghlrdhorhhgpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfohhunhgurghtih honhdrohhrghdprhgtphhtthhopegsohhquhhnrdhfvghnghesghhmrghilhdrtghomhdp rhgtphhtthhopegtohhrsggvtheslhifnhdrnhgvthdprhgtphhtthhopehmrghrkhdrrh huthhlrghnugesrghrmhdrtghomhdprhgtphhtthhopegrrhhnugesrghrnhgusgdruggv pdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqrghrtghhsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Oct 2025 19:51:05 -0400 (EDT) To: Peter Zijlstra , Will Deacon Cc: Andrew Morton , Boqun Feng , Jonathan Corbet , Mark Rutland , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Geert Uytterhoeven , linux-m68k@vger.kernel.org, Lance Yang Message-ID: In-Reply-To: References: From: Finn Thain Subject: [RFC v3 3/5] atomic: Specify alignment for atomic_t and atomic64_t Date: Wed, 08 Oct 2025 09:19:20 +1100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Some recent commits incorrectly assumed 4-byte alignment of locks. That assumption fails on Linux/m68k (and, interestingly, would have failed on Linux/cris also). Specify the minimum alignment of atomic variables for fewer surprises and (hopefully) better performance. On an m68k system with 14 MB of RAM, this patch reduces the available memory by a couple of percent. On a 64 MB system, the cost is under 1% but still significant. I don't know whether there is sufficient performance gain to justify the memory cost; it still has to be measured. Cc: Lance Yang Link: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr= 8_g58Rc1_0g@mail.gmail.com/ --- Changed since v2: - Specify natural alignment for atomic64_t. Changed since v1: - atomic64_t now gets an __aligned attribute too. - The 'Fixes' tag has been dropped because Lance sent a different fix for commit e711faaafbe5 ("hung_task: replace blocker_mutex with encoded blocker") that's suitable for -stable. --- include/asm-generic/atomic64.h | 2 +- include/linux/types.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h index 100d24b02e52..f22ccfc0df98 100644 --- a/include/asm-generic/atomic64.h +++ b/include/asm-generic/atomic64.h @@ -10,7 +10,7 @@ #include =20 typedef struct { - s64 counter; + s64 __aligned(sizeof(s64)) counter; } atomic64_t; =20 #define ATOMIC64_INIT(i) { (i) } diff --git a/include/linux/types.h b/include/linux/types.h index 6dfdb8e8e4c3..a225a518c2c3 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -179,7 +179,7 @@ typedef phys_addr_t resource_size_t; typedef unsigned long irq_hw_number_t; =20 typedef struct { - int counter; + int __aligned(sizeof(int)) counter; } atomic_t; =20 #define ATOMIC_INIT(i) { (i) } --=20 2.49.1 From nobody Sat Feb 7 22:07:14 2026 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 2F6B12609E3; Tue, 7 Oct 2025 23:51:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.159 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881079; cv=none; b=IUhfmf3UsfxE9Q8E3FQKR+1oMGYAPBAiMQ4mSucYkuPWuJXljoFCBYsfz5sUwdvWzRSMrukM2MdgLnls8iASGJ7zbaZroU5exQAhKcNBZGaAo1IU23Znach4moNbjKNKd1c+aQTvWtQLR1W2fonIVtX7wg52UM430a0Rde21PLs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881079; c=relaxed/simple; bh=GKdlckKpBwoWz5SmGQFW80sWaAJ08k8SalMYCE+PBNo=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=fHIknu7mITFZAbdR/maUbLGn59AAIfF4b+cu5PerBRuq02UQlcfrcKarn4MVcUYBtlAyNllRqu/45gLInwSg2rAMQ5zR2IVwulMuG8kXAF+5fRvyFPUtkK9XdIpcNfIXKUgRcX43UU9ipuTOEEFCqtZeoI+Ei+MansQ6L63F2RA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=none smtp.mailfrom=linux-m68k.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=LmXpd90W; arc=none smtp.client-ip=202.12.124.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="LmXpd90W" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 286547A0053; Tue, 7 Oct 2025 19:51:17 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 07 Oct 2025 19:51:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1759881077; x= 1759967477; bh=DD225BAPYeK+qLAmHgDY4jpXzvMfC78Rnw2xeRu8mXU=; b=L mXpd90WTcdzuY6vfRLjk3FOg+iPrJZxa1c95OhUSKBFGEPU9vKn1FxNaoraxAoCd UwDjMzFZzEvkftKbZASva5DXe5CvWBoKND6GcKVOxu7PhrQGy5l+NH2zl3sOVJmE OkQL0K1EJPwYWrtDfMfc+M4vEW88X0q0+U28MxM/L1Yd/fE0xizoPW0QwRRC+wT8 nt7VD6VKFVK49i6a8IxibknrOAsTh9Wb9+Bvaf1wDmTQlNoonLROEF3Qpanhs5pg NmecH1X3g2YbsIWA+A66w+AHLpn44eV+6FI32vTxy8diw+4jrt2NtnNzT8MI/Iwu RXjNajBnyh+C6B7qxQimw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddutddujeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeehkeduffehjedvieevkeelleegffeiuddvgeeluefhuedugeekkeehffekgffgheen ucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgepudenuc frrghrrghmpehmrghilhhfrhhomhepfhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhr ghdpnhgspghrtghpthhtohepuddupdhmohguvgepshhmthhpohhuthdprhgtphhtthhope hpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtthhopeifihhllheskhgv rhhnvghlrdhorhhgpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfohhunhgurghtih honhdrohhrghdprhgtphhtthhopegsohhquhhnrdhfvghnghesghhmrghilhdrtghomhdp rhgtphhtthhopegtohhrsggvtheslhifnhdrnhgvthdprhgtphhtthhopehmrghrkhdrrh huthhlrghnugesrghrmhdrtghomhdprhgtphhtthhopegrrhhnugesrghrnhgusgdruggv pdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqrghrtghhsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Oct 2025 19:51:14 -0400 (EDT) To: Peter Zijlstra , Will Deacon Cc: Andrew Morton , Boqun Feng , Jonathan Corbet , Mark Rutland , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Geert Uytterhoeven , linux-m68k@vger.kernel.org Message-ID: In-Reply-To: References: From: Finn Thain Subject: [RFC v3 4/5] atomic: Add alignment check to instrumented atomic operations Date: Wed, 08 Oct 2025 09:19:20 +1100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Peter Zijlstra Add a Kconfig option for debug builds which logs a warning when an instrumented atomic operation takes place that's misaligned. Some platforms don't trap for this. Link: https://lore.kernel.org/lkml/20250901093600.GF4067720@noisy.programmi= ng.kicks-ass.net/ --- Changed since v2: - Always check for natural alignment. --- To make this useful on those architectures that don't naturally align scalars (x86-32, m68k and sh come to mind), please also use "[PATCH] atomic: skip alignment check for try_cmpxchg() old arg" https://lore.kernel.org/all/20251006110740.468309-1-arnd@kernel.org/ --- include/linux/instrumented.h | 4 ++++ lib/Kconfig.debug | 10 ++++++++++ 2 files changed, 14 insertions(+) diff --git a/include/linux/instrumented.h b/include/linux/instrumented.h index 711a1f0d1a73..402a999a0d6b 100644 --- a/include/linux/instrumented.h +++ b/include/linux/instrumented.h @@ -7,6 +7,7 @@ #ifndef _LINUX_INSTRUMENTED_H #define _LINUX_INSTRUMENTED_H =20 +#include #include #include #include @@ -67,6 +68,7 @@ static __always_inline void instrument_atomic_read(const = volatile void *v, size_ { kasan_check_read(v, size); kcsan_check_atomic_read(v, size); + WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); } =20 /** @@ -81,6 +83,7 @@ static __always_inline void instrument_atomic_write(const= volatile void *v, size { kasan_check_write(v, size); kcsan_check_atomic_write(v, size); + WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); } =20 /** @@ -95,6 +98,7 @@ static __always_inline void instrument_atomic_read_write(= const volatile void *v, { kasan_check_write(v, size); kcsan_check_atomic_read_write(v, size); + WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); } =20 /** diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index ebe33181b6e6..d82626b7d6be 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1363,6 +1363,16 @@ config DEBUG_PREEMPT depending on workload as it triggers debugging routines for each this_cpu operation. It should only be used for debugging purposes. =20 +config DEBUG_ATOMIC + bool "Debug atomic variables" + depends on DEBUG_KERNEL + help + If you say Y here then the kernel will add a runtime alignment check + to atomic accesses. Useful for architectures that do not have trap on + mis-aligned access. + + This option has potentially significant overhead. + menu "Lock Debugging (spinlocks, mutexes, etc...)" =20 config LOCK_DEBUGGING_SUPPORT --=20 2.49.1 From nobody Sat Feb 7 22:07:14 2026 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 8884A224AF3; Tue, 7 Oct 2025 23:51:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.159 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881090; cv=none; b=Xmfu5rFXyyZJAVnEtetUbd0ah3hC6yKURZnahLVjW8/j36EzL5aGjnPKBTfjI9cnGXua1SGalhK6FqlR7YgjIvjgacWwXsi24lQZr7Wfl3I0qXZqTQ20/P9AabImCkXBZW97OW5w54jCjjnC5VEfL2jTks+rCNZb3xoj8Ab2fyA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759881090; c=relaxed/simple; bh=rNKE9ngzFrHTLxZ7ppLHn5u6VEyDnMzzG91YPYVvxwk=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=YGgrgYbrVKVWUcf8gB6DoLGRXtl31mSad3iPWUvfcnDeMPHPTfjJsB+RTpXp9H3EPs8BdYoXg0H+UhcCuig8idhwlcyjM7FBcfxIiJ7PWgElk32S/fsT2gb+w29ALf8I6pQUDUBmkusvDNy2+7ZF+bqAtoErqccGAOs3lG75Kqw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=none smtp.mailfrom=linux-m68k.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=JHETawTw; arc=none smtp.client-ip=202.12.124.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="JHETawTw" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id 7AFC37A0078; Tue, 7 Oct 2025 19:51:27 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 07 Oct 2025 19:51:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1759881087; x= 1759967487; bh=0+AdSH1sg/8lok7qtu/8oSLYuGUe0/34ymLa0qtNzl8=; b=J HETawTwt13D+PZ6+SnHOUkOkfOJixRcK2mEAmqGP9fpoGn44euJSdk/y6ZUdjCJa Zu2nqtmiu4dUjKnK4Gv0OMaOLlqKB+wYcw52F4noBx6gmiLeoWEEQtM4Z/icdxyP 8AZjWUk9mf8kK+NxCH/bIHz4+Dgwe9yhN5q9jTGEzLbHlQLUnY1KJTjZre61HCF2 ojSmMhMJPsvQM+63pKCrHlQxmNcGM6dF6TvkcY1jbI4DKTq+wj0wT7banc71UaDX 6Zz7Lv22bvTQRnbPe/E7QGDoamgPSG2wGe16cMam/fCvmbZYIEHRMOmWpMBquu7H xvsmi84AS8IS673L98zyw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddutddujeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeevgffgtdfhhfefveeuudfgtdeugfeftedtveekieeggfduleetgeegueehgeffffen ucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfthhhrg hinheslhhinhhugidqmheikehkrdhorhhgpdhnsggprhgtphhtthhopeduuddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepphgvthgvrhiisehinhhfrhgruggvrggurdhorh hgpdhrtghpthhtohepfihilhhlsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrkhhp mheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepsghoqhhunh drfhgvnhhgsehgmhgrihhlrdgtohhmpdhrtghpthhtoheptghorhgsvghtsehlfihnrdhn vghtpdhrtghpthhtohepmhgrrhhkrdhruhhtlhgrnhgusegrrhhmrdgtohhmpdhrtghpth htoheprghrnhgusegrrhhnuggsrdguvgdprhgtphhtthhopehlihhnuhigqdhkvghrnhgv lhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdgrrhgthh esvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Oct 2025 19:51:24 -0400 (EDT) To: Peter Zijlstra , Will Deacon Cc: Andrew Morton , Boqun Feng , Jonathan Corbet , Mark Rutland , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Geert Uytterhoeven , linux-m68k@vger.kernel.org Message-ID: In-Reply-To: References: From: Finn Thain Subject: [RFC v3 5/5] atomic: Add option for weaker alignment check Date: Wed, 08 Oct 2025 09:19:20 +1100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Add a new Kconfig symbol to make CONFIG_DEBUG_ATOMIC more useful on those architectures which do not align dynamic allocations to 8-byte boundaries. Without this, CONFIG_DEBUG_ATOMIC produces excessive WARN splats. --- include/linux/instrumented.h | 14 +++++++++++--- lib/Kconfig.debug | 9 +++++++++ 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/include/linux/instrumented.h b/include/linux/instrumented.h index 402a999a0d6b..3c9a570dbfa7 100644 --- a/include/linux/instrumented.h +++ b/include/linux/instrumented.h @@ -8,11 +8,13 @@ #define _LINUX_INSTRUMENTED_H =20 #include +#include #include #include #include #include #include +#include =20 /** * instrument_read - instrument regular read access @@ -68,7 +70,9 @@ static __always_inline void instrument_atomic_read(const = volatile void *v, size_ { kasan_check_read(v, size); kcsan_check_atomic_read(v, size); - WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC)) + WARN_ON_ONCE(v !=3D PTR_ALIGN(v, IS_ENABLED(CONFIG_DEBUG_ATOMIC_LARGEST_= ALIGN) ? + __LARGEST_ALIGN : size)); } =20 /** @@ -83,7 +87,9 @@ static __always_inline void instrument_atomic_write(const= volatile void *v, size { kasan_check_write(v, size); kcsan_check_atomic_write(v, size); - WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC)) + WARN_ON_ONCE(v !=3D PTR_ALIGN(v, IS_ENABLED(CONFIG_DEBUG_ATOMIC_LARGEST_= ALIGN) ? + __LARGEST_ALIGN : size)); } =20 /** @@ -98,7 +104,9 @@ static __always_inline void instrument_atomic_read_write= (const volatile void *v, { kasan_check_write(v, size); kcsan_check_atomic_read_write(v, size); - WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC)) + WARN_ON_ONCE(v !=3D PTR_ALIGN(v, IS_ENABLED(CONFIG_DEBUG_ATOMIC_LARGEST_= ALIGN) ? + __LARGEST_ALIGN : size)); } =20 /** diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d82626b7d6be..f81b8a9b9216 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1373,6 +1373,15 @@ config DEBUG_ATOMIC =20 This option has potentially significant overhead. =20 +config DEBUG_ATOMIC_LARGEST_ALIGN + bool "Check alignment only up to __LARGEST_ALIGN" + depends on DEBUG_ATOMIC + help + Say Y here if you require natural alignment of atomic accesses + only up to long word boundaries. That is, char, short, int and long + will be checked for natural alignment but anything larger checked + only for alignment with a long word boundary. + menu "Lock Debugging (spinlocks, mutexes, etc...)" =20 config LOCK_DEBUGGING_SUPPORT --=20 2.49.1