[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <9fbb6bf2-70ae-4d49-9221-751d28dcfd1a@redhat.com>
Date: Tue, 30 Dec 2025 15:07:10 -0600
From: Eric Sandeen <sandeen@...hat.com>
To: linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-kernel@...r.kernel.org
Cc: Christian Brauner <brauner@...nel.org>,
David Howells <dhowells@...hat.com>, lkp@...el.com, oe-lkp@...ts.linux.dev,
Alexander Viro <aviro@...hat.com>
Subject: [PATCH RFC] fs: cache-align lock_class_keys in struct
file_system_type
LKP reported that one of their tests was failing to even boot with my
"old mount API code" removal patch. The test was booting an i386 kernel
under QEMU, with lockdep enabled. Rather than a functional failure, it
seemed to have been slowed to a crawl and eventually timed out.
I narrowed the problem down to the removal of the ->mount op from
file_system_type, which changed structure alignment and seems to have
caused cacheline issues with this structure. Annotating the alignment
fixes the problem for me.
Reported-by: kernel test robot <oliver.sang@...el.com>
Closes: https://lore.kernel.org/oe-lkp/202512230315.1717476b-lkp@intel.com
Fixes: 51a146e05 ("fs: Remove internal old mount API code")
Signed-off-by: Eric Sandeen <sandeen@...hat.com>
---
RFC because I honestly don't understand why this should be so critical,
especially the structure was not explicitly (or even very well) aligned
before. I would welcome insights from folks who are smarter than me!
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 9949d253e5aa..b3d8cad15de1 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2279,7 +2279,7 @@ struct file_system_type {
struct file_system_type * next;
struct hlist_head fs_supers;
- struct lock_class_key s_lock_key;
+ struct lock_class_key s_lock_key ____cacheline_aligned;
struct lock_class_key s_umount_key;
struct lock_class_key s_vfs_rename_key;
struct lock_class_key s_writers_key[SB_FREEZE_LEVELS];
Powered by blists - more mailing lists