Re: [PATCH] locking/mutex: Redo __mutex_init()

From: Waiman Long

Date: Wed Nov 05 2025 - 08:49:45 EST


On 11/5/25 2:57 AM, Sebastian Andrzej Siewior wrote:
On 2025-11-04 11:21:27 [-0500], Waiman Long wrote:
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+void mutex_init_ld(struct mutex *lock, const char *name, struct lock_class_key *key);
+
+static inline void __mutex_init(struct mutex *lock, const char *name,
+ struct lock_class_key *key)
+{
+ mutex_init_ld(lock, name, key);
+}
+#else
+extern void mutex_init_plain(struct mutex *lock);
+
+static inline void __mutex_init(struct mutex *lock, const char *name,
+ struct lock_class_key *key)
+{
+ mutex_init_plain(lock);
+}
+#endif /* !CONFIG_DEBUG_LOCK_ALLOC */
I think it is a good idea to eliminate useless strings in non-lockdep
kernel. However, the function names are kind of awkward to me. First of all,
it is hard to associate "ld" with lockdep as ld is also the name of the GNU
linker. I would prefer to fully spell out as "lockdep". The "_plain" suffix
also looks odd to me. How about using the original __mutex_init for the
plain version and __mutex_init_lockdep as the lockdep version which calls
__mutex_init and use similar naming scheme for the RT versions. What do you
think?
What about
mutex_init_plain() -> mutex_init_generic()
mutex_init_ld() -> mutex_init_lockdep()
Yes, generic is a much better name.

Using __mutex_init() for the basic/ generic init could work but we have
already users 13 users (drivers/ mm/ net/) and the rust bindings are
also attached to it. I would prefer the generic/ lockdep suffix.

If you want __mutex_init() for the generic, regardless, we would first
need to make room and then something like mutex_init_lockdep() could be
the public interface replacing __mutex_init() in its current function.

Ah, I don't realize that there are users of __mutex_init() outside of the locking subsystem. In this case, we have to maintain the semantics of __mutex_init() to avoid affecting other subsystems.

Thanks for the clarification.

Cheers,
Longman