Re: [PATCH v5 10/36] locking/mutex: Support Clang's context analysis

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.