Re: Linux 6.15-rc3

[Michael Larabel <Michael@phoronix.com>]

On 4/23/25 3:08 AM, Vlastimil Babka wrote:
> On 4/23/25 10:03, Vlastimil Babka wrote:
>> On 4/23/25 09:14, Vlastimil Babka wrote:
>>
>> Oh I see, replacing the default: which "local_lock_t *:" which is the only
>> other expected type, forces the compiler to actually tell me what's wrong:
>>
>> ./include/linux/local_lock_internal.h:174:26: error: ‘_Generic’ selector of
>> type ‘__seg_gs local_lock_t *’ is not compatible with any association
>>
>>
> This should fix the issue hopefully and prevent more unexpected default matches:
>
> diff --git a/include/linux/local_lock_internal.h b/include/linux/local_lock_internal.h
> index bf2bf40d7b18..8d5ac16a9b17 100644
> --- a/include/linux/local_lock_internal.h
> +++ b/include/linux/local_lock_internal.h
> @@ -102,11 +102,11 @@ do {								\
>   		l = (local_lock_t *)this_cpu_ptr(lock);			\
>   		tl = (local_trylock_t *)l;				\
>   		_Generic((lock),					\
> -			local_trylock_t *: ({				\
> +			__percpu local_trylock_t *: ({			\
>   				lockdep_assert(tl->acquired == 0);	\
>   				WRITE_ONCE(tl->acquired, 1);		\
>   			}),						\
> -			default:(void)0);				\
> +			__percpu local_lock_t *: (void)0);		\
>   		local_lock_acquire(l);					\
>   	} while (0)
>   
> @@ -171,11 +171,11 @@ do {								\
>   		tl = (local_trylock_t *)l;				\
>   		local_lock_release(l);					\
>   		_Generic((lock),					\
> -			local_trylock_t *: ({				\
> +			__percpu local_trylock_t *: ({			\
>   				lockdep_assert(tl->acquired == 1);	\
>   				WRITE_ONCE(tl->acquired, 0);		\
>   			}),						\
> -			default:(void)0);				\
> +			__percpu local_lock_t *: (void)0);		\
>   	} while (0)
>   
>   #define __local_unlock(lock)					\
>
>

In addition to fixing the Nginx performance, I can confirm this patch 
does also fix the other regressions I found as well caused by 51339d99c 
with Memcached, ClickHouse, and OpenFOAM. All the tests I have been 
running with current Git + this patch have been working out well and 
haven't noticed any other problems from it. Will keep running through 
some more workloads on that server but seems to now be in good shape.

Thanks,

Michael


Tested-by: Michael Larabel <Michael@phoronix.com>