Thread (17 messages) 17 messages, 6 authors, 2023-12-14

Re: [PATCH v3 03/11] devm-helpers: introduce devm_mutex_init

From: Andy Shevchenko <hidden>
Date: 2023-12-13 22:39:53
Also in: linux-leds, lkml

On Thu, Dec 14, 2023 at 12:30 AM George Stark [off-list ref] wrote:
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 wrapper.
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() is
extended so introduce devm_mutex_init().
...
+#ifdef mutex_destroy
+static inline void devm_mutex_release(void *res)
+{
+       mutex_destroy(res);
+}
+#endif
+
+/**
+ * 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.
+ */
+static inline int devm_mutex_init(struct device *dev, struct mutex *lock)
+{
+       mutex_init(lock);
+#ifdef mutex_destroy
+       return devm_add_action_or_reset(dev, devm_mutex_release, lock);
+#else
+       return 0;
+#endif
+}
If this is going to be accepted, you may decrease the amount of ifdeffery.

#ifdef ...
#else
#define devm_mutex_init(dev, lock)  mutex_init(lock)
#endif


-- 
With Best Regards,
Andy Shevchenko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help