From nobody Fri Oct 2 07:45:42 2026 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CBCCD3F1ABD for ; Tue, 4 Aug 2026 06:40:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785825614; cv=none; b=q4VCwC0/EURFk/Lzahelq5GYkcQKQ9rgYvsGR7/qdffuowGgxknMBJSpsrrbhxg1oenHmoBoLkRGCDwnhVHri3XFvrrQRPoN4rDfBAykokieYfxcpuWXtZJ0oaaSEFMnYmMhNgbZZWf8Uni0MH4aQxX4pykSLfoB423E28fML9I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785825614; c=relaxed/simple; bh=zy4ivbcsLi4a9BOqMqtScND+kBuVlrUnkjpIGiCRDRI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=WrnO7eh9aBScuW+uS/sjpw64To/VoPVMN3EM64sSweSYmDwbs5nkWy70VxKaa/Q3KEdNMWIOh0PugTQN2smEPn0wKJx7VEA2cgFSoLoVdVMQsNRwsBVF7VLbgW8FihcUAp1DrBVZEaF5tVhcFT3/eLPqOBhlOi3Nx21Q6+pIpcE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fxu4IcSs; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fxu4IcSs" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-47fdd674e17so1314517f8f.1 for ; Mon, 03 Aug 2026 23:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785825611; x=1786430411; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=a5chIgkfvPI0jWeizxya1HdKcbXp0ioz5d3+92bdzJo=; b=fxu4IcSsJQNFEkBwpSbzC9ZF7wBzL8WH56PWONGJ7eOW5yfRloHdSXaSoQ+T9rWiZK +cUn11SzfX/mg6gYnkgPA/R9I+Q8U6tVd8Efkiy82ObJ6exb9y0/w/S5fSYJ4LEBR0UH YCTezX8/gqdTt5tOSRxmRjzBQn5fcqJC/UxushYN7rdFfPmMCF76FxgBs1gE62pXzql4 A6/hKSNOpes5eRWyitfoAhlG56ebff37Pav2nImtn8MDehKmSxjlI1rBlxPkv5fecLbn NCMRoBxyjOSTLRXrgBgR0umKXMVw/eRnHqxlbVDY4v2+fF14onjRgiuFybonRXO696w/ aaXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785825611; x=1786430411; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a5chIgkfvPI0jWeizxya1HdKcbXp0ioz5d3+92bdzJo=; b=UyNsUtGrbSOLLxFQ338VfkwCgCIpA9KiU95sM7DM3fQYrvPVEl37e9YGPczuU/Frfy lTVueOWRHjyR9mODQ6ZFcaneLr9guuvsQiwIKo5Cua7CSntNvQhQ/RyYb4N/LqqQmuXs nHmJu82ONg0n5Vj8dhKidogFEnmkbhL61vgALpgsMppFtwllyC/D7AGlp9E1YQ1YXMIF rIXMIML+8ySLVHQ3NbJZWRNCWwFLXj1ICeqXA1Mgrr9bgDD/5iF6D1cogwxQlb6/a43V Gd1+erhXEFYyA7aFpYaghn/BiNMWaebCoFAI9V4ojhTNjC2wKiW5nFrqwwcPXtpWRgBv C9cw== X-Forwarded-Encrypted: i=1; AHgh+RrOBZjDrVH5PNjQI8+RICP+sq34c6Bnlje88e6h1zez4mp4JwkH2ByGRoMnDe0hZcX2BqnZht+A/lejWvE=@vger.kernel.org X-Gm-Message-State: AOJu0YzCIcF3UqebkPtcZkl6h98RwCu6eHBMRfEk893Ob+dF4rmnaK49 Ismyvzl6wVFWKlLsW97zFb9RmhxvVn4CphrcYGpXiKZP4Ws/AtKKySR2 X-Gm-Gg: AR+sD10UCcS/s+gMXhs+LJATJpvonFAZS3SSPmdhRJ8A6/fWzqnvya3/efws0XB9uLw 5ll+uBM9MyQKWc9F1pcrJ3FtH6k0tUVOeXukkaFBwx5zs5kFTYm9zd/mS1oMtUK1vNx//n5476Q OuEWfjJVPLlcBnZLuAlBKNujMw8Jd/23ygg0VbJjHqXXljQJYGiHwEhBM9Qk1EB4eT0jNVUuTXL SYLXq9eEolUtLCTJaXHWGTz7yQZHC8TkQM5lfjQxANaCo5Bc7dQWy9S4TauD66IHvNUQsXzu0CF rZJO3RGr5tN4Ei9giXk6IMfsdMbKKSSsrH4V9F5VV1cdc2zETyuoiYg3hz9SFofOIeaKCG3iUQo nbZaPdtwwAcj9CoGzLLkzTMv+a0hwGXzhFm2v+xhLTW66Nh3AJ3hjjYcQ14zIE+P8M5T8xzKjMA V+V9TFO5N//j/ZiTfW44JvDVvzvLe4tNIKnTJ+nIVw62M2DVv79rWEH7LL9d9ZkP65tNk7454Nx 6e4pQGt82Q8tVoQC4xCmmu9Vy7GrfJe9BZxjLuGvoeQ2BM/JkUsaLKDlzbsIVP9bndwnAJcWUXd 58Dm21OKFdrgiSUbruIgoV+PkMNLbQv9tBmgxPfWnNusyLz4at6lOC6wJTCRJDemG3bCZgXBUd2 bXm2BjuqoJMg= X-Received: by 2002:a5d:6586:0:b0:47f:5b52:5579 with SMTP id ffacd0b85a97d-47fd72d4a27mr23930087f8f.18.1785825610759; Mon, 03 Aug 2026 23:40:10 -0700 (PDT) Received: from MacBook-Pro-von-Karl.localdomain (dynamic-2a02-3100-a48b-1c01-1c76-d8bb-0f26-1c8f.310.pool.telefonica.de. [2a02:3100:a48b:1c01:1c76:d8bb:f26:1c8f]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd45a0c8bsm38525785f8f.34.2026.08.03.23.40.09 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 03 Aug 2026 23:40:10 -0700 (PDT) From: Karl Mehltretter To: Ingo Molnar , Peter Zijlstra , Andrew Morton Cc: Karl Mehltretter , Kees Cook , Vlastimil Babka , Bradley Morgan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] fork: Honor task_struct's declared alignment Date: Tue, 4 Aug 2026 08:40:06 +0200 Message-Id: <20260804064006.93930-1-kmehltretter@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Since commit cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size"), struct task_struct is declared __attribute__((aligned(64))) on all architectures. But fork_init() sets the task_struct slab cache's alignment to align =3D max(L1_CACHE_BYTES, ARCH_MIN_TASKALIGN) which is smaller than 64 on architectures whose cache lines are below 64 bytes: e.g. 32 on ARMv5. In practice plain SLUB happens to hand out 64-byte-aligned objects anyway. With CONFIG_SLUB_DEBUG_ON the red-zone padding shifts objects to the requested alignment. With CONFIG_UBSAN_ALIGNMENT=3Dy a boot on QEMU versatilepb (ARM926EJ-S, v7.2-rc2, gcc 13.3) floods the console with reports like: UBSAN: misaligned-access in include/linux/sched.h:2087:9 member access within misaligned address c295d7e0 for type 'struct task_st= ruct' which requires 64 byte alignment CPU: 0 UID: 0 PID: 15 Comm: pr/ttyAMA-1 Not tainted 7.2.0-rc2 #1 VOLUNTARY Set the slab alignment to at least the type's declared alignment. Replace the hardcoded L1_CACHE_BYTES with SLAB_HWCACHE_ALIGN so the allocator applies cache_line_size(). On x86, arm and arm64 that is the cache line size of the booted CPU. Everywhere else it falls back to L1_CACHE_BYTES and nothing changes. ARCH_MIN_TASKALIGN (e.g. 4096 with x86 VSMP) still applies through the explicit align argument. Fixes: cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size") Suggested-by: Vlastimil Babka (SUSE) Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Reviewed-by: Bradley Morgan Reviewed-by: Vlastimil Babka (SUSE) --- Notes (format-patch): v2: - fold in Vlastimil's suggestion: let SLAB_HWCACHE_ALIGN replace the hardcoded L1_CACHE_BYTES v1: https://lore.kernel.org/all/20260710123957.31774-1-kmehltretter@gma= il.com/ kernel/fork.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index f0e2e131a9a5..3a0093efb29f 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -857,14 +857,15 @@ void __init fork_init(void) #ifndef ARCH_MIN_TASKALIGN #define ARCH_MIN_TASKALIGN 0 #endif - int align =3D max_t(int, L1_CACHE_BYTES, ARCH_MIN_TASKALIGN); + int align =3D max(ARCH_MIN_TASKALIGN, + __alignof__(struct task_struct)); unsigned long useroffset, usersize; =20 /* create a slab on which task_structs can be allocated */ task_struct_whitelist(&useroffset, &usersize); task_struct_cachep =3D kmem_cache_create_usercopy("task_struct", arch_task_struct_size, align, - SLAB_PANIC|SLAB_ACCOUNT, + SLAB_PANIC|SLAB_ACCOUNT|SLAB_HWCACHE_ALIGN, useroffset, usersize, NULL); =20 /* do the arch specific task caches init */ base-commit: af5e34a41cd607c00ef752e00331736570992354 --=20 2.39.5 (Apple Git-154)