use_ww_ctx is equivalent to ww_ctx != NULL. The one case where
use_ww_ctx was true but ww_ctx == NULL leads to the same
__mutex_add_waiter() call via __ww_mutex_add_waiter().

Since now __ww_mutex_add_waiter() is called only with ww_mutex != NULL,
remove the branch there.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 kernel/locking/mutex.c    | 16 ++++++----------
 kernel/locking/ww_mutex.h |  5 -----
 2 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index d973fe6041bf..2f0e318233f5 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -568,15 +568,12 @@ EXPORT_SYMBOL(ww_mutex_unlock);
 static __always_inline int __sched
 __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclass,
 		    struct lockdep_map *nest_lock, unsigned long ip,
-		    struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
+		    struct ww_acquire_ctx *ww_ctx)
 {
 	struct mutex_waiter waiter;
 	struct ww_mutex *ww;
 	int ret;
 
-	if (!use_ww_ctx)
-		ww_ctx = NULL;
-
 	might_sleep();
 
 	MUTEX_WARN_ON(lock->magic != lock);
@@ -627,12 +624,11 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
 
 	debug_mutex_lock_common(lock, &waiter);
 	waiter.task = current;
-	if (use_ww_ctx)
-		waiter.ww_ctx = ww_ctx;
+	waiter.ww_ctx = ww_ctx;
 
 	lock_contended(&lock->dep_map, ip);
 
-	if (!use_ww_ctx) {
+	if (!ww_ctx) {
 		/* add waiting tasks to the end of the waitqueue (FIFO): */
 		__mutex_add_waiter(lock, &waiter, &lock->wait_list);
 	} else {
@@ -744,14 +740,14 @@ static int __sched
 __mutex_lock(struct mutex *lock, unsigned int state, unsigned int subclass,
 	     struct lockdep_map *nest_lock, unsigned long ip)
 {
-	return __mutex_lock_common(lock, state, subclass, nest_lock, ip, NULL, false);
+	return __mutex_lock_common(lock, state, subclass, nest_lock, ip, NULL);
 }
 
 static int __sched
 __ww_mutex_lock(struct mutex *lock, unsigned int state, unsigned int subclass,
 		unsigned long ip, struct ww_acquire_ctx *ww_ctx)
 {
-	return __mutex_lock_common(lock, state, subclass, NULL, ip, ww_ctx, true);
+	return __mutex_lock_common(lock, state, subclass, NULL, ip, ww_ctx);
 }
 
 /**
@@ -831,7 +827,7 @@ mutex_lock_io_nested(struct mutex *lock, unsigned int subclass)
 
 	token = io_schedule_prepare();
 	__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE,
-			    subclass, NULL, _RET_IP_, NULL, 0);
+			    subclass, NULL, _RET_IP_, NULL);
 	io_schedule_finish(token);
 }
 EXPORT_SYMBOL_GPL(mutex_lock_io_nested);
diff --git a/kernel/locking/ww_mutex.h b/kernel/locking/ww_mutex.h
index 3ad2cc4823e5..11acb2efe976 100644
--- a/kernel/locking/ww_mutex.h
+++ b/kernel/locking/ww_mutex.h
@@ -493,11 +493,6 @@ __ww_mutex_add_waiter(struct MUTEX_WAITER *waiter,
 	struct MUTEX_WAITER *cur, *pos = NULL;
 	bool is_wait_die;
 
-	if (!ww_ctx) {
-		__ww_waiter_add(lock, waiter, NULL);
-		return 0;
-	}
-
 	is_wait_die = ww_ctx->is_wait_die;
 
 	/*
-- 
2.39.2

On 8/30/23 18:12, Michał Mirosław wrote:
> use_ww_ctx is equivalent to ww_ctx != NULL. The one case where
> use_ww_ctx was true but ww_ctx == NULL leads to the same
> __mutex_add_waiter() call via __ww_mutex_add_waiter().
I think ww_mutex_lock() can be called with a NULL ctx. Your patch will 
effectively change those ww_mutex_lock() to be equivalent to 
mutex_lock(). So it is a behavioral change.
> Since now __ww_mutex_add_waiter() is called only with ww_mutex != NULL,
> remove the branch there.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>   kernel/locking/mutex.c    | 16 ++++++----------
>   kernel/locking/ww_mutex.h |  5 -----
>   2 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index d973fe6041bf..2f0e318233f5 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -568,15 +568,12 @@ EXPORT_SYMBOL(ww_mutex_unlock);
>   static __always_inline int __sched
>   __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclass,
>   		    struct lockdep_map *nest_lock, unsigned long ip,
> -		    struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
> +		    struct ww_acquire_ctx *ww_ctx)
>   {
>   	struct mutex_waiter waiter;
>   	struct ww_mutex *ww;
>   	int ret;
>   
> -	if (!use_ww_ctx)
> -		ww_ctx = NULL;
> -
That code is probably not needed given the current usage. Perhaps, you 
can change it to "WARN_ON_ONCE(ww_ctx && !use_ww_ctx);"
>   	might_sleep();
>   
>   	MUTEX_WARN_ON(lock->magic != lock);
> @@ -627,12 +624,11 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
>   
>   	debug_mutex_lock_common(lock, &waiter);
>   	waiter.task = current;
> -	if (use_ww_ctx)
> -		waiter.ww_ctx = ww_ctx;
> +	waiter.ww_ctx = ww_ctx;
This one is fine.
>   
>   	lock_contended(&lock->dep_map, ip);
>   
> -	if (!use_ww_ctx) {
> +	if (!ww_ctx) {
That change will break ww_mutex.

Cheers,
Longman

On Wed, Aug 30, 2023 at 07:54:13PM -0400, Waiman Long wrote:
> On 8/30/23 18:12, Michał Mirosław wrote:
> > use_ww_ctx is equivalent to ww_ctx != NULL. The one case where
> > use_ww_ctx was true but ww_ctx == NULL leads to the same
> > __mutex_add_waiter() call via __ww_mutex_add_waiter().
> I think ww_mutex_lock() can be called with a NULL ctx. Your patch will
> effectively change those ww_mutex_lock() to be equivalent to mutex_lock().
> So it is a behavioral change.

Isn't ww_mutex_lock() with ctx = NULL expected to behave like mutex_lock()?

> > Since now __ww_mutex_add_waiter() is called only with ww_mutex != NULL,
> > remove the branch there.
[...]
> > @@ -627,12 +624,11 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
> >   	debug_mutex_lock_common(lock, &waiter);
> >   	waiter.task = current;
> > -	if (use_ww_ctx)
> > -		waiter.ww_ctx = ww_ctx;
> > +	waiter.ww_ctx = ww_ctx;
> This one is fine.
> >   	lock_contended(&lock->dep_map, ip);
> > -	if (!use_ww_ctx) {
> > +	if (!ww_ctx) {
> That change will break ww_mutex.

I see that there is the rt_mutex version that stubs out
__ww_mutex_add_waiter(), but its ww_mutex_lock() doesn't use
__mutex_lock_common() at all. With the RT version out of the picture, we
can see that __ww_mutex_add_waiter(), when passed ww_ctx == NULL, just
forwards the work to __ww_waiter_add() with the same arguments
and returns 0 -- making the path exactly as the !use_ww_ctx branch.

Note: There is a lot of templating-via-preprocessor code here and I
might have missed something. I'll appreciate hints here as maybe it
could be made simpler or better understood.

Best Regards
Michał Mirosław

On 9/2/23 13:06, Michał Mirosław wrote:
> On Wed, Aug 30, 2023 at 07:54:13PM -0400, Waiman Long wrote:
>> On 8/30/23 18:12, Michał Mirosław wrote:
>>> use_ww_ctx is equivalent to ww_ctx != NULL. The one case where
>>> use_ww_ctx was true but ww_ctx == NULL leads to the same
>>> __mutex_add_waiter() call via __ww_mutex_add_waiter().
>> I think ww_mutex_lock() can be called with a NULL ctx. Your patch will
>> effectively change those ww_mutex_lock() to be equivalent to mutex_lock().
>> So it is a behavioral change.
> Isn't ww_mutex_lock() with ctx = NULL expected to behave like mutex_lock()?
>
>>> Since now __ww_mutex_add_waiter() is called only with ww_mutex != NULL,
>>> remove the branch there.
> [...]
>>> @@ -627,12 +624,11 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
>>>    	debug_mutex_lock_common(lock, &waiter);
>>>    	waiter.task = current;
>>> -	if (use_ww_ctx)
>>> -		waiter.ww_ctx = ww_ctx;
>>> +	waiter.ww_ctx = ww_ctx;
>> This one is fine.
>>>    	lock_contended(&lock->dep_map, ip);
>>> -	if (!use_ww_ctx) {
>>> +	if (!ww_ctx) {
>> That change will break ww_mutex.
> I see that there is the rt_mutex version that stubs out
> __ww_mutex_add_waiter(), but its ww_mutex_lock() doesn't use
> __mutex_lock_common() at all. With the RT version out of the picture, we
> can see that __ww_mutex_add_waiter(), when passed ww_ctx == NULL, just
> forwards the work to __ww_waiter_add() with the same arguments
> and returns 0 -- making the path exactly as the !use_ww_ctx branch.
>
> Note: There is a lot of templating-via-preprocessor code here and I
> might have missed something. I'll appreciate hints here as maybe it
> could be made simpler or better understood.

Yes, I have misread the code thinking that __ww_waiter_add() with a NULL 
third argument is different from __mutex_add_waiter(). They the same in 
this case for the non-PREEMPT_RT kernel. For the PREEMPT_RT kernel, 
however, they are still different.

Cheers,
Longman

On 9/2/23 15:40, Waiman Long wrote:
> On 9/2/23 13:06, Michał Mirosław wrote:
>> On Wed, Aug 30, 2023 at 07:54:13PM -0400, Waiman Long wrote:
>>> On 8/30/23 18:12, Michał Mirosław wrote:
>>>> use_ww_ctx is equivalent to ww_ctx != NULL. The one case where
>>>> use_ww_ctx was true but ww_ctx == NULL leads to the same
>>>> __mutex_add_waiter() call via __ww_mutex_add_waiter().
>>> I think ww_mutex_lock() can be called with a NULL ctx. Your patch will
>>> effectively change those ww_mutex_lock() to be equivalent to 
>>> mutex_lock().
>>> So it is a behavioral change.
>> Isn't ww_mutex_lock() with ctx = NULL expected to behave like 
>> mutex_lock()?
>>
>>>> Since now __ww_mutex_add_waiter() is called only with ww_mutex != 
>>>> NULL,
>>>> remove the branch there.
>> [...]
>>>> @@ -627,12 +624,11 @@ __mutex_lock_common(struct mutex *lock, 
>>>> unsigned int state, unsigned int subclas
>>>>        debug_mutex_lock_common(lock, &waiter);
>>>>        waiter.task = current;
>>>> -    if (use_ww_ctx)
>>>> -        waiter.ww_ctx = ww_ctx;
>>>> +    waiter.ww_ctx = ww_ctx;
>>> This one is fine.
>>>> lock_contended(&lock->dep_map, ip);
>>>> -    if (!use_ww_ctx) {
>>>> +    if (!ww_ctx) {
>>> That change will break ww_mutex.
>> I see that there is the rt_mutex version that stubs out
>> __ww_mutex_add_waiter(), but its ww_mutex_lock() doesn't use
>> __mutex_lock_common() at all. With the RT version out of the picture, we
>> can see that __ww_mutex_add_waiter(), when passed ww_ctx == NULL, just
>> forwards the work to __ww_waiter_add() with the same arguments
>> and returns 0 -- making the path exactly as the !use_ww_ctx branch.
>>
>> Note: There is a lot of templating-via-preprocessor code here and I
>> might have missed something. I'll appreciate hints here as maybe it
>> could be made simpler or better understood.
>
> Yes, I have misread the code thinking that __ww_waiter_add() with a 
> NULL third argument is different from __mutex_add_waiter(). They the 
> same in this case for the non-PREEMPT_RT kernel. For the PREEMPT_RT 
> kernel, however, they are still different.

OTOH, the rtmutex code will not call __ww_mutex_add_waiter() with NULL 
ww_ctx. So in that sense, the patch is probably OK. You will need to 
expand the patch description to also describe the case for PREEMPT_RT 
kernel.

Cheers,
Longman