linux-kernel - Improving mutex_init() optimisation for !lockdep

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: <20250623092832.nmgJY7V5@linutronix.de>
Date: Mon, 23 Jun 2025 11:28:32 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: linux-kernel@...r.kernel.org
Cc: Boqun Feng <boqun.feng@...il.com>, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>
Subject: Improving mutex_init() optimisation for !lockdep

Hi,

while looking at the assembly of something else I stumbled upon
code that originated from mutex_int() on a !LOCKDEP kernel.
We have this macro:

| #define mutex_init(mutex)                                               \
| do {                                                                    \
|         static struct lock_class_key __key;                             \
|                                                                         \
|         __mutex_init((mutex), #mutex, &__key);                          \
| } while (0)

and the compiler computed an offset for __key and an offset and storage
for #mutex. These two arguments aren't used by __mutex_init() but the
compiler can't know that.
If I remove these two arguments on a x86-64 defconfig, I see:

|    text     data     bss      dec     hex filename
| 29753523 8033942 1306232 39093697 25485c1 vmlinux.before
| 29748880 8021654 1306168 39076702 254435e vmlinux.after
|     4643   12288      64    16995  0x4263 diff in bytes

That is 4KiB in text and 12KiB in data. I don't know why we lost 64
bytes in BSS.

Any objections in redoing this to save some bytes?

Sebastian