Le 14/12/2023 à 19:48, Waiman Long a écrit :

On 12/14/23 12:36, George Stark wrote:

quoted

Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
Since mutex_destroy() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() will be
extended so introduce devm_mutex_init()

Signed-off-by: George Stark <redacted>
---
  include/linux/mutex.h        | 23 +++++++++++++++++++++++
  kernel/locking/mutex-debug.c | 22 ++++++++++++++++++++++
  2 files changed, 45 insertions(+)

diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index a33aa9eb9fc3..ebd03ff1ef66 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h

@@ -21,6 +21,8 @@

  #include <linux/debug_locks.h>
  #include <linux/cleanup.h>
+struct device;
+
  #ifdef CONFIG_DEBUG_LOCK_ALLOC
  # define __DEP_MAP_MUTEX_INITIALIZER(lockname)            \
          , .dep_map = {                    \

@@ -127,6 +129,20 @@ extern void __mutex_init(struct mutex *lock, 

const char *name,
   */
  extern bool mutex_is_locked(struct mutex *lock);
+#ifdef CONFIG_DEBUG_MUTEXES
+
+int devm_mutex_init(struct device *dev, struct mutex *lock);

Please add "extern" to the function declaration to be consistent with 
other functional declarations in mutex.h.

'extern' is pointless and deprecated on function prototypes. Already 
having some is not a good reason to add new ones, errors from the past 
should be avoided nowadays. With time they should all disappear so don't 
add new ones.

quoted

+
+#else
+
+static inline int devm_mutex_init(struct device *dev, struct mutex 
*lock)
+{
+    mutex_init(lock);
+    return 0;
+}

I would prefer you to add a devm_mutex_init macro after the function 
declaration and put this inline function at the end of header if the 
devm_mutex_init macro isn't defined. In this way, you don't need to 
repeat this inline function twice as it has no dependency on PREEMPT_RT.

It is already done that way for other functions in that file. Should be 
kept consistant. I agree with you it is not ideal, maybe we should 
rework that file completely but I don't like the idea of a 
devm_mutex_init macro for that.

Christophe

By doing this, you can also move the function declaration right after 
mutex_destroy() without the need to add another #ifdef 
CONFIG_DEBUG_MUTEXES block.

quoted

+
+#endif
+
  #else /* !CONFIG_PREEMPT_RT */
  /*
   * Preempt-RT variant based on rtmutexes.

@@ -169,6 +185,13 @@ do {                            \

                              \
      __mutex_init((mutex), #mutex, &__key);        \
  } while (0)
+
+static inline int devm_mutex_init(struct device *dev, struct mutex 
*lock)
+{
+    mutex_init(lock);
+    return 0;
+}
+
  #endif /* CONFIG_PREEMPT_RT */
  /*

diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
index bc8abb8549d2..c9efab1a8026 100644
--- a/kernel/locking/mutex-debug.c
+++ b/kernel/locking/mutex-debug.c

@@ -19,6 +19,7 @@

  #include <linux/kallsyms.h>
  #include <linux/interrupt.h>
  #include <linux/debug_locks.h>
+#include <linux/device.h>
  #include "mutex.h"

@@ -104,3 +105,24 @@ void mutex_destroy(struct mutex *lock)

  }
  EXPORT_SYMBOL_GPL(mutex_destroy);
+
+static void devm_mutex_release(void *res)
+{
+    mutex_destroy(res);
+}
+
+/**
+ * devm_mutex_init - Resource-managed mutex initialization
+ * @dev:    Device which lifetime mutex is bound to
+ * @lock:    Pointer to a mutex
+ *
+ * Initialize mutex which is automatically destroyed when the driver 
is detached.
+ *
+ * Returns: 0 on success or a negative error code on failure.
+ */
+int devm_mutex_init(struct device *dev, struct mutex *lock)
+{
+    mutex_init(lock);
+    return devm_add_action_or_reset(dev, devm_mutex_release, lock);
+}
+EXPORT_SYMBOL_GPL(devm_mutex_init);

The mutex-debug.c change looks fine to me.

Cheers,
Longman