linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <20250623104234.GQ1613200@noisy.programming.kicks-ass.net>
Date: Mon, 23 Jun 2025 12:42:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Boqun Feng <boqun.feng@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Waiman Long <longman@...hat.com>,
	Will Deacon <will@...nel.org>
Subject: Re: Improving mutex_init() optimisation for !lockdep

On Mon, Jun 23, 2025 at 11:28:32AM +0200, Sebastian Andrzej Siewior wrote:
> 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?

Nope, easy win :-)