From nobody Sat Feb 7 08:43:29 2026 Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) (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 B9B622C235D; Tue, 13 Jan 2026 05:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282692; cv=none; b=VeKn8ExdHP0vhTwm2gSKXvk551/qQcXm349ENWphCY6seDTYVyfo+JMirne9BzZpfOe/QCMaIMxtQcnCmetrvfBiyvPmiOCCFVr6tKqZ4REoiheiji3cOIZffbLnXODwOokn1j+ZR5fufSBltVhMkBQNOH+P3YzeIaqgBkqJr10= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282692; c=relaxed/simple; bh=6BaawB/5vhO7v/rumx07zT9BPZyyoYZDc4iUgex6uao=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=joqkWf3zcI9ENORlrSHPkQLBUrtFBg7CIVtfX5wNbcmQLSk4z/lU7m7AW/IDIWh/ZlE5pXjcSBncU7tnjBE2Keb5M0igFqouUuLu1KVkiVWDyIhOiWe4U3qFYjUcr3dSOwoo0SeuoHH0VxiveoZq04FPck3RUp1sExVcRlmWNcA= 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=BkdaaE9/; arc=none smtp.client-ip=202.12.124.156 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="BkdaaE9/" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 7E5EA7A0095; Tue, 13 Jan 2026 00:38:09 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 13 Jan 2026 00:38:10 -0500 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=1768282689; x= 1768369089; bh=nL9oXUgaQPIU6S4mzvMLiKSGthFWHu05i1DeuxQmtGs=; b=B kdaaE9/oX7QGz5QHKWUNZ4An3q2fXEMCkfsh4lC+F9/IEaVj1yMi10ugkkWh4O9X 1/M3K8L0CEozQLX7MnMDdc8sc9aAucY5J2IUrhom4LApPHwQ0Yz0qdg6YTG0drtw LzrS+P/p9tHKdwmQE0hVAqqMwuPbbhJNY51ydx4rgXtzJQ72GA1KnNIqoDZGmV7e 8C6RmkBR7ZBGbQwqK5zwsLZxCM/VQR727BCqvFxhc5r1WfU7L3xQdq2/yoTitzO4 ngADxD4rYNH3cOdIK34ws/L23izVcc+CZzh2hS+ngTMyBZnGyVYar0IzTBix98rP u4pdL9xHfPudO3ShY4y0g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduudelhedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeevgffgtdfhhfefveeuudfgtdeugfeftedtveekieeggfduleetgeegueehgeffffen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfthhhrg hinheslhhinhhugidqmheikehkrdhorhhgpdhnsggprhgtphhtthhopedvgedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfohhunhgurghtih honhdrohhrghdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdp rhgtphhtthhopeifihhllheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghrnhguse grrhhnuggsrdguvgdprhgtphhtthhopegsohhquhhnrdhfvghnghesghhmrghilhdrtgho mhdprhgtphhtthhopehgrghrhiesghgrrhihghhuohdrnhgvthdprhgtphhtthhopehmrg hrkhdrrhhuthhlrghnugesrghrmhdrtghomhdprhgtphhtthhopehlihhnuhigqdgrrhgt hhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnh gvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Jan 2026 00:38:05 -0500 (EST) To: Andrew Morton , Peter Zijlstra , Will Deacon Cc: Arnd Bergmann , Boqun Feng , Gary Guo , Mark Rutland , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Geert Uytterhoeven , bpf@vger.kernel.org Message-ID: <8a83876b07d1feacc024521e44059ae89abbb1ea.1768281748.git.fthain@linux-m68k.org> In-Reply-To: References: From: Finn Thain Subject: [PATCH v7 1/4] bpf: Explicitly align bpf_res_spin_lock Date: Tue, 13 Jan 2026 16:22:28 +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 from 2 to 4. Drop the BUILD_BUG_ON() as it becomes redundant. Cc: Geert Uytterhoeven Cc: linux-m68k@lists.linux-m68k.org Acked-by: Alexei Starovoitov Reviewed-by: Arnd Bergmann Signed-off-by: Finn Thain --- Changed since v5: - Added tag from Arnd Bergmann. --- 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 0f2dcbbfee2f..dd36ac96bf66 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 f7d0c8d4644e..8d892fb099ac 100644 --- a/kernel/bpf/rqspinlock.c +++ b/kernel/bpf/rqspinlock.c @@ -694,7 +694,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 08:43:29 2026 Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) (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 C2B5A2C235D; Tue, 13 Jan 2026 05:38:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282705; cv=none; b=shg62/AD+fwstuqeEuxv4eRrz33crhwdM3DFiO2oulN7+MVn6FfzDrAo3sLS4YPG7B91ThtP961cvU8vPN0fUYu6F1so5XS7y6So+oePfN2GL+SrTA2LsWZzbKdTc3iGli87643Xh0lW+VwLwy6mgiZu3z3+RglCBr2UwgVZSqQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282705; c=relaxed/simple; bh=TVBYg+2G0DLr0zMyrc3vdOsG1553YTGNnc2V942V/Bw=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=mVyu03FPbDLB9VZ9MaJ9G3bsWfHlCUxNbD0vJlMhoAy2H9Wl3LDwIzFGYANl24Us8bW6Gs6BFW2y0Su+BITePePVZ75PEI1VvMwKcxGcGmhrabvjJU8nLhpPtB5GSZl3HWP79HFnOTPywxyzPz682y2Fk311y707BSCX3ugsWhU= 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=ByJH5Iks; arc=none smtp.client-ip=202.12.124.156 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="ByJH5Iks" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 66C077A0095; Tue, 13 Jan 2026 00:38:21 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Tue, 13 Jan 2026 00:38:22 -0500 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=1768282701; x= 1768369101; bh=CsktC8xD5EhNAbS2AjeT72YR6CfdK+yufEdKYFi5oBo=; b=B yJH5Iksp+s2dl2BeWNT3+0GXbL4pFiKVsqQIuA5LP7MZcGQPzrzLzVVOY/gd3jB7 DmdH4tLHsdFYTg3Y0O6peSyDn0ebLh8xGPCX+ho0WzIBPgL65IsYmgyqitQUURwH /UHfYmmrpcfb2An26uoJHQRjteEsb7QbKXjia2ULzcAq+AADrr7AzXwqZYBAbIOm HQB8KFZzG5l6WyzfjbB/74WUFrmGduqob7rlQ7/kPkK5xe4itM5h2ZQWE92+225X 8KzYvdr9wJZC9pFsglfdGzZL++P//5GUy5cWPxPl10jcySHCK5IOyUMMp5ZamB82 /XkQWKFU71TrkZn2cCRPQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduudelhedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeehkeduffehjedvieevkeelleegffeiuddvgeeluefhuedugeekkeehffekgffgheen ucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepfhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhr ghdpnhgspghrtghpthhtohepvddvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhope grkhhpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepphgv thgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepfihilhhlsehkvghrnh gvlhdrohhrghdprhgtphhtthhopegrrhhnugesrghrnhgusgdruggvpdhrtghpthhtohep sghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmpdhrtghpthhtohepghgrrhihsehgrg hrhihguhhordhnvghtpdhrtghpthhtohepmhgrrhhkrdhruhhtlhgrnhgusegrrhhmrdgt ohhmpdhrtghpthhtoheplhhinhhugidqrghrtghhsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdho rhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Jan 2026 00:38:19 -0500 (EST) To: Andrew Morton , Peter Zijlstra , Will Deacon Cc: Arnd Bergmann , Boqun Feng , Gary Guo , Mark Rutland , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Guo Ren , linux-csky@vger.kernel.org, Geert Uytterhoeven , Dinh Nguyen , Jonas Bonn , Stefan Kristiansson , Stafford Horne , linux-openrisc@vger.kernel.org, Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , linux-sh@vger.kernel.org Message-ID: In-Reply-To: References: From: Finn Thain Subject: [PATCH v7 2/4] atomic: Specify alignment for atomic_t and atomic64_t Date: Tue, 13 Jan 2026 16:22:28 +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). The jump label implementation makes a similar alignment assumption. The expectation that atomic_t and atomic64_t variables will be naturally aligned seems reasonable, as indeed they are on 64-bit architectures. But atomic64_t isn't naturally aligned on csky, m68k, microblaze, nios2, openrisc and sh. Neither atomic_t nor atomic64_t are naturally aligned on m68k. This patch brings a little uniformity by specifying natural alignment for atomic types. One benefit is that atomic64_t variables do not get split across a page boundary. The cost is that some structs grow which leads to cache misses and wasted memory. See also, commit bbf2a330d92c ("x86: atomic64: The atomic64_t data type should be 8 bytes aligned on 32-bit too"). Cc: Guo Ren Cc: linux-csky@vger.kernel.org Cc: Geert Uytterhoeven Cc: linux-m68k@lists.linux-m68k.org Cc: Dinh Nguyen Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: linux-openrisc@vger.kernel.org Cc: Yoshinori Sato Cc: Rich Felker Cc: John Paul Adrian Glaubitz Cc: linux-sh@vger.kernel.org Link: https://lore.kernel.org/lkml/CAFr9PX=3DMYUDGJS2kAvPMkkfvH+0-SwQB_kxE4= ea0J_wZ_pk=3D7w@mail.gmail.com Link: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr= 8_g58Rc1_0g@mail.gmail.com/ Acked-by: Guo Ren Reviewed-by: Arnd Bergmann Signed-off-by: Finn Thain --- Changed since v5: - Added tags from Guo Ren and Arnd Bergmann. 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 d4437e9c452c..1760e1feeab9 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -180,7 +180,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 08:43:29 2026 Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) (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 127E535CB69; Tue, 13 Jan 2026 05:38:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.149 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282716; cv=none; b=AT8+L31amNodj5ir78DnYCPVK/KSmJ8aQI6RvZ5fnVexYDEblMWyj7LbJTYFFVGklRSiQYfCplW9ek5W5SkPJnxYktBwnqEcQgGlL3b2jjS8Dy6hBYna62WpaZyLL5uUjlRrX7kOw1lDc8o06KIPpz/O8RrSGpIwyYYGeuC/OJY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282716; c=relaxed/simple; bh=bZKri+q8JzKy6ytJBb/Ncm9BqY+ao0ZKXtsoGhyWbEU=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=iJmoOikh3JpsFDWSbEbmjvpWisBJuEmtYOcFcl76ZiBB1aSkx1CpdeRnQwwD6HLjoi1vD0XbNN6Ls3FQ28lrdeFHAOdw/Bgly8hXybHdl86RgMNPR/b6yg1BtKeDHjgKusZsz8QuMo2ga2pmrKTeZ6fEWex+HJWM0t1GhxIdUEs= 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=pYIfNDkv; arc=none smtp.client-ip=202.12.124.149 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="pYIfNDkv" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.stl.internal (Postfix) with ESMTP id 175B51D000E0; Tue, 13 Jan 2026 00:38:34 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 13 Jan 2026 00:38:34 -0500 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=1768282713; x= 1768369113; bh=jiBMJymXYYttEEG2SfWequihow3tSncHan9khHjXFzU=; b=p YIfNDkvSxwFB6PTTFMTN+zdBumshQl9Xl8MQ212eVNGTeD+Kg8VP85Hila8UsKy2 /W3y3zAS99sEhVVl2Djw0V5rg1EQgv9oBUuqsWTbGemSJA7rQTWJDh2eEwneInNf Eu2NuJRCP6xg5vZFgFvA2zUdMe5XqdEXt7SglroconqEnRlZzYS6aWuWirWyCQf9 ZAL/94jAl0doRDsjNouG361zR79zBAZMQMaUzxBHCK7bScUKIw+ksANBpLaTdq4L MvKUpxr0gS3+34ZK2ZWuhATvt3JgN0ZtQpKrxW/6JbOCsEzpWnco3zuK9kOETztM WyZPtUhYTWhuWlnDxPIuw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduudelhedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeehkeduffehjedvieevkeelleegffeiuddvgeeluefhuedugeekkeehffekgffgheen ucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepfhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhr ghdpnhgspghrtghpthhtohepudejpdhmohguvgepshhmthhpohhuthdprhgtphhtthhope grkhhpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepphgv thgvrhiisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepfihilhhlsehkvghrnh gvlhdrohhrghdprhgtphhtthhopegrrhhnugesrghrnhgusgdruggvpdhrtghpthhtohep sghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmpdhrtghpthhtohepghgrrhihsehgrg hrhihguhhordhnvghtpdhrtghpthhtohepmhgrrhhkrdhruhhtlhgrnhgusegrrhhmrdgt ohhmpdhrtghpthhtoheplhhinhhugidqrghrtghhsehvghgvrhdrkhgvrhhnvghlrdhorh hgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdho rhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Jan 2026 00:38:30 -0500 (EST) To: Andrew Morton , Peter Zijlstra , Will Deacon Cc: Arnd Bergmann , Boqun Feng , Gary Guo , Mark Rutland , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Sasha Levin , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Ard Biesheuvel , "H. Peter Anvin" Message-ID: <51ebf844e006ca0de408f5d3a831e7b39d7fc31c.1768281748.git.fthain@linux-m68k.org> In-Reply-To: References: From: Finn Thain Subject: [PATCH v7 3/4] atomic: Add alignment check to instrumented atomic operations Date: Tue, 13 Jan 2026 16:22:28 +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. [ fthain: added __DISABLE_EXPORTS conditional and refactored as helper function. ] Cc: Sasha Levin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Ard Biesheuvel Cc: "H. Peter Anvin" Link: https://lore.kernel.org/lkml/20250901093600.GF4067720@noisy.programmi= ng.kicks-ass.net/ Link: https://lore.kernel.org/linux-next/df9fbd22-a648-ada4-fee0-68fe4325ff= 82@linux-m68k.org/ Signed-off-by: Finn Thain --- Checkpatch.pl says... ERROR: Missing Signed-off-by: line by nominal patch author 'Peter Ziljstra = ' --- Changed since v6: - Implemented helper function earlier in patch series, as requested by Ard. - Dropped __DISABLE_BUG_TABLE macro in favour of __DISABLE_EXPORTS, as requested by Peter. Changed since v5: - Add new __DISABLE_BUG_TABLE macro to prevent a build failure on those architectures which use atomics in pre-boot code like the EFI stub loader: x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from `arc= h/x86/boot/compressed/sev-handle-vc.o' Changed since v2: - Always check for natural alignment. --- include/linux/instrumented.h | 11 +++++++++++ lib/Kconfig.debug | 10 ++++++++++ 2 files changed, 21 insertions(+) diff --git a/include/linux/instrumented.h b/include/linux/instrumented.h index 711a1f0d1a73..e34b6a557e0a 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 @@ -55,6 +56,13 @@ static __always_inline void instrument_read_write(const = volatile void *v, size_t kcsan_check_read_write(v, size); } =20 +static __always_inline void instrument_atomic_check_alignment(const volati= le void *v, size_t size) +{ +#ifndef __DISABLE_EXPORTS + WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); +#endif +} + /** * instrument_atomic_read - instrument atomic read access * @v: address of access @@ -67,6 +75,7 @@ static __always_inline void instrument_atomic_read(const = volatile void *v, size_ { kasan_check_read(v, size); kcsan_check_atomic_read(v, size); + instrument_atomic_check_alignment(v, size); } =20 /** @@ -81,6 +90,7 @@ static __always_inline void instrument_atomic_write(const= volatile void *v, size { kasan_check_write(v, size); kcsan_check_atomic_write(v, size); + instrument_atomic_check_alignment(v, size); } =20 /** @@ -95,6 +105,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); + instrument_atomic_check_alignment(v, size); } =20 /** diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index ba36939fda79..4b4d1445ef9c 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1359,6 +1359,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 08:43:29 2026 Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) (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 8BB2535B127; Tue, 13 Jan 2026 05:38:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.149 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282726; cv=none; b=biQsDk3XsPsS/XcVT1F/zHkTFeiuONoZhOJQbOdUyhlYqO5jMOdRrhwo41lngueWHf6bE4ENwLJicWK0Kbs34GCQBtP0i1gnPa0pjNF+VVPka1phdgNtL7rInyj/a5HOmx2TVQToi5Z6F2whnUeaUx8twK8LMCrO1EgmPVjzFrQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768282726; c=relaxed/simple; bh=OWh8njjsogK8OZKE0gH6MErCWwee1eb7vZZ80vE+0TE=; h=To:Cc:Message-ID:In-Reply-To:References:From:Subject:Date; b=FFWwn7QDnMeIwMfXjnxE702bZIul1fUUThOPk+EoIGCgHXE4PwVoZJkZtmqFYWmQmyb/XXGF10dQaLF+KnXnIreOAVqdx88/+KMxLHD1f2+rfYiPRiE6gdvvmJ+SrJq7mvWGWznlvu4cYtxcO0tQlbv7NpK26QYQZ7bDh1UpoL0= 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=iYyhii0f; arc=none smtp.client-ip=202.12.124.149 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="iYyhii0f" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.stl.internal (Postfix) with ESMTP id C7F531D00142; Tue, 13 Jan 2026 00:38:44 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 13 Jan 2026 00:38:45 -0500 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=1768282724; x= 1768369124; bh=ycpRkHG759Ns/LsRddK7ctIaYu+SsUoRWuefNhT6tys=; b=i Yyhii0fzWjaiSQ+kRHXhEEV6wQMWKKtiv59fCZDrdXyo9vlZWAjASXOvsDjoQkY4 BO0Fp3BhFe4vQXcYN9zTvhBjy5HGEK05PNOz1EZqvlEbpGeF1kYG4MEUxhgPfpvY vpBemnfhGcm+HkxaTc7vY4yG5W5jEtff97qqB9W/Ojw3Lyj7Y6O/5vJJ1MfQT0Cf tWq1O5Zp1N2YRer2PFZ2DHI0b+hvEXI6uSwo5qGiYV2ChdXBy4EclNf767A8ectC dAv8r2yTRCKzzh0OTEIBoiFE6YAt/Fw4RDYrUwm0HAQid+BEaacB1pOez0BypOz2 qAVCrX8ywMVOW5JAWDU+A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduudelhedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepvfevkfgjfhfhufffsedttdertddttddtnecuhfhrohhmpefhihhnnhcuvfhhrghi nhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtthgvrh hnpeevgffgtdfhhfefveeuudfgtdeugfeftedtveekieeggfduleetgeegueehgeffffen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfthhhrg hinheslhhinhhugidqmheikehkrdhorhhgpdhnsggprhgtphhtthhopedutddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfohhunhgurghtih honhdrohhrghdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdp rhgtphhtthhopeifihhllheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghrnhguse grrhhnuggsrdguvgdprhgtphhtthhopegsohhquhhnrdhfvghnghesghhmrghilhdrtgho mhdprhgtphhtthhopehgrghrhiesghgrrhihghhuohdrnhgvthdprhgtphhtthhopehmrg hrkhdrrhhuthhlrghnugesrghrmhdrtghomhdprhgtphhtthhopehlihhnuhigqdgrrhgt hhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnh gvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Jan 2026 00:38:42 -0500 (EST) To: Andrew Morton , Peter Zijlstra , Will Deacon Cc: Arnd Bergmann , Boqun Feng , Gary Guo , Mark Rutland , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org Message-ID: <6d25a12934fe9199332f4d65d17c17de450139a8.1768281748.git.fthain@linux-m68k.org> In-Reply-To: References: From: Finn Thain Subject: [PATCH v7 4/4] atomic: Add option for weaker alignment check Date: Tue, 13 Jan 2026 16:22:28 +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. Signed-off-by: Finn Thain --- Changed since v6: - Rebased. Changed since v5: - Rebased. Changed since v3: - Dropped #include to avoid a build failure on arm64. - Rewrote Kconfig help text to better describe preferred alignment. - Refactored to avoid line-wrapping and duplication. --- include/linux/instrumented.h | 8 +++++++- lib/Kconfig.debug | 8 ++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/include/linux/instrumented.h b/include/linux/instrumented.h index e34b6a557e0a..a1b4cf81adc2 100644 --- a/include/linux/instrumented.h +++ b/include/linux/instrumented.h @@ -59,7 +59,13 @@ static __always_inline void instrument_read_write(const = volatile void *v, size_t static __always_inline void instrument_atomic_check_alignment(const volati= le void *v, size_t size) { #ifndef __DISABLE_EXPORTS - WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size= - 1))); + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC)) { + unsigned int mask =3D size - 1; + + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_LARGEST_ALIGN)) + mask &=3D sizeof(struct { long x; } __aligned_largest) - 1; + WARN_ON_ONCE((unsigned long)v & mask); + } #endif } =20 diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 4b4d1445ef9c..977a2c9163a2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1369,6 +1369,14 @@ config DEBUG_ATOMIC =20 This option has potentially significant overhead. =20 +config DEBUG_ATOMIC_LARGEST_ALIGN + bool "Check alignment only up to __aligned_largest" + depends on DEBUG_ATOMIC + help + If you say Y here then the check for natural alignment of + atomic accesses will be constrained to the compiler's largest + alignment for scalar types. + menu "Lock Debugging (spinlocks, mutexes, etc...)" =20 config LOCK_DEBUGGING_SUPPORT --=20 2.49.1