Hello Christophe
On 12/15/23 08:46, Christophe Leroy wrote:
Le 14/12/2023 à 22:48, Waiman Long a écrit :
On 12/14/23 14:53, Christophe Leroy wrote:
Le 14/12/2023 à 19:48, Waiman Long a écrit :
On 12/14/23 12:36, George Stark 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 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 <gnstark@xxxxxxxxxxxxxxxxx>
---
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.
Yes, "extern" is optional. It is just a suggestion and I am going to
argue about that.
FWIW, note that when you perform a strict check with checkpatch.pl, you
get a warning for that:
$ ./scripts/checkpatch.pl --strict -g HEAD
CHECK: extern prototypes should be avoided in .h files
#56: FILE: include/linux/mutex.h:131:
+extern int devm_mutex_init(struct device *dev, struct mutex *lock);
total: 0 errors, 0 warnings, 1 checks, 99 lines checked
This is ambiguous situation about extern. It's deprecated and useless on
one hand but harmless. And those externs will not disappear by themself
- it'll be one patch that clean them all at once (in one header at
least) so one more extern will not alter the overall picture.
On the other hand if we manage to place devm_mutex_init near
mutex_destroy then we'll have:
int devm_mutex_init(struct device *dev, struct mutex *lock);
extern void mutex_destroy(struct mutex *lock);
and it raises questions and does not look very nice.
+
+#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.
devm_mutex_init() is not an API for the core mutex code. That is why I
want to minimize change to the existing code layout. Putting it at the
end will reduce confusion when developers look up mutex.h header file to
find out what mutex functions are available.
If I look at linux/gpio.h we are more or less in the same situation I think.
devm_mutex_init() is not an API for the core mutex code, but developers
need to know the managed functions for mutex exist, and having them at
the same place as non managed functions looks better to me. Now I agree
with you that this duplication of functions is not the best, and it also
applies to existing content of mutex.h so maybe we can do something
about it later and improve the situation.
Christophe
--
Best regards
George
