On 12/19/25 8:39 AM, Marco Elver wrote:
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index bf535f0118bb..89977c215cbd 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -62,6 +62,7 @@ do {
\
static struct lock_class_key __key; \
\
__mutex_init((mutex), #mutex, &__key); \
+ __assume_ctx_lock(mutex); \
} while (0)
The above type of change probably will have to be reverted. If I enable
context analysis for the entire kernel tree, drivers/base/devcoredump.c
doesn't build. The following error is reported:
drivers/base/devcoredump.c:406:2: error: acquiring mutex '_res->mutex'
that is already held [-Werror,-Wthread-safety-analysis]
406 | mutex_lock(&devcd->mutex);
| ^
dev_coredumpm_timeout() calls mutex_init() and mutex_lock() from the
same function. The above type of change breaks compilation of all code
that initializes and locks a synchronization object from the same
function. My understanding of dev_coredumpm_timeout() is that there is a
good reason for calling both mutex_init() and mutex_lock() from that
function. Possible solutions are disabling context analysis for that
function or removing __assume_ctx_lock() again from mutex_init(). Does
anyone want to share their opinion about this?
Thanks,
Bart.
