linux-kernel - [PATCH] dcache: don't discard dentry_hashtable or d_hash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240829182049.287086-1-stephen.s.brennan@oracle.com>
Date: Thu, 29 Aug 2024 11:20:49 -0700
From: Stephen Brennan <stephen.s.brennan@...cle.com>
To: Christian Brauner <brauner@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-debuggers@...r.kernel.org, Jan Kara <jack@...e.cz>,
        Stephen Brennan <stephen.s.brennan@...cle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH] dcache: don't discard dentry_hashtable or d_hash_shift

The runtime constant feature removes all the users of these variables,
allowing the compiler to optimize them away. It's quite difficult to
extract their values from the kernel text, and the memory saved by
removing them is tiny, and it was never the point of this optimization.

Since the dentry_hashtable is a core data structure, it's valuable for
debugging tools to be able to read it easily. For instance, scripts built
on drgn, like the dentrycache script[1], rely on it to be able to perform
diagnostics on the contents of the dcache. Annotate it as used, so the
compiler doesn't discard it.

[1]: https://github.com/oracle-samples/drgn-tools/blob/3afc56146f54d09dfd1f6d3c1b7436eda7e638be/drgn_tools/dentry.py#L325-L355

Fixes: e3c92e81711d ("runtime constants: add x86 architecture support")
Signed-off-by: Stephen Brennan <stephen.s.brennan@...cle.com>
---

Hi Christian, Al, Linus,

I know this "fix" may seem a bit silly, but reading out the dentry
hashtable contents from a core dump or live system has been a real life
saver when debugging dentry cache bloat issues. Could we do something
like this (even making it opt-in would be great) for v6.11?

Thanks,
Stephen

 fs/dcache.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 3d8daaecb6d1a..69404b4d87546 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -96,11 +96,16 @@ EXPORT_SYMBOL(dotdot_name);
  *
  * This hash-function tries to avoid losing too many bits of hash
  * information, yet avoid using a prime hash-size or similar.
+ *
+ * Marking the variables "used" ensures that the compiler doesn't
+ * optimize them away completely on architectures with runtime
+ * constant infrastructure, this allows debuggers to see their
+ * values. But updating these values has no on those arches.
  */

-static unsigned int d_hash_shift __ro_after_init;
+static unsigned int d_hash_shift __ro_after_init __used;

-static struct hlist_bl_head *dentry_hashtable __ro_after_init;
+static struct hlist_bl_head *dentry_hashtable __ro_after_init __used;

 static inline struct hlist_bl_head *d_hash(unsigned long hashlen)
 {
-- 
2.43.5