linux-kernel - Re: register_syctl_init error in linux-next-20250612

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ue32pzorcdfcj4i7xtvq5qcpkw2vcvnnc3dvuovl7t4vuxrkyi@efk3ptq7fy73>
Date: Mon, 23 Jun 2025 09:55:40 +0200
From: Joel Granados <joel.granados@...nel.org>
To: Bert Karwatzki <spasswolf@....de>
Cc: linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, 
	Waiman Long <longman@...hat.com>, Kees Cook <kees@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: register_syctl_init error in linux-next-20250612

On Fri, Jun 20, 2025 at 01:17:15PM +0200, Bert Karwatzki wrote:
> Am Freitag, dem 20.06.2025 um 13:11 +0200 schrieb Joel Granados:
> > On Fri, Jun 20, 2025 at 11:37:40AM +0200, Bert Karwatzki wrote:
> > > Am Donnerstag, dem 19.06.2025 um 14:39 +0200 schrieb Joel Granados:
> > > > On Thu, Jun 12, 2025 at 07:55:13PM +0200, Bert Karwatzki wrote:

...

> > 
> > Did you have the chance to test with the patch that I sent?
> > 
> > Best
> 
> I did not test your patch, but it seems I independently came up with the
> same soulution: 
> 
> It seems to be a compile/file include issue: kernel/locking/rtmutex.c is not compiled
> via a Makefile but it's included in via #include:
> 
> $ rg "include.*rtmutex.c\>"
> kernel/locking/rwsem.c
> 1405:#include "rtmutex.c"
> 
> kernel/locking/spinlock_rt.c
> 25:#include "rtmutex.c"
> 
> kernel/locking/ww_rt_mutex.c
> 10:#include "rtmutex.c"
> 
> kernel/locking/rtmutex_api.c
> 9:#include "rtmutex.c"
> 
> which in the case of PREEMPT_RT=y leads to four call to init_rtmutex_sysctl().
> 
> I solved this by moving the code to kernel/locking/rtmutex_api.c:
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 705a0e0fd72a..cf24eacef48d 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -34,24 +34,6 @@
> */
> static int max_lock_depth = 1024;

I think leaving max_lock_depth hear is not a good idea. Every time rtmutex.c is
included, it will create a private (inside the scope of the file that is
including rtmutex.c) copy of max_lock_depth. This might not result in
misbehavior at the outset, but it increases the potential for trouble.

For now I'll push my original fix to next. Which leaves the definition
of max_lock_depth in rtmutex_api.c avoiding multiptle definitions when
rtmutex.c is included in other files.

Also: CCing maintainers to see if they have any additional info.

Best

> -static const struct ctl_table rtmutex_sysctl_table[] = {
> - {
> - .procname = "max_lock_depth",
> - .data = &max_lock_depth,
> - .maxlen = sizeof(int),
> - .mode = 0644,
> - .proc_handler = proc_dointvec,
> - },
> -};
> -
> -static int __init init_rtmutex_sysctl(void)
> -{
> - register_sysctl_init("kernel", rtmutex_sysctl_table);
> - return 0;
> -}
> -
> -subsys_initcall(init_rtmutex_sysctl);
> -
> #ifndef WW_RT
> # define build_ww_mutex() (false)
> # define ww_container_of(rtm) NULL
> diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c
> index 9e00ea0e5cfa..a133870b4519 100644
> --- a/kernel/locking/rtmutex_api.c
> +++ b/kernel/locking/rtmutex_api.c
> @@ -8,6 +8,24 @@
> #define RT_MUTEX_BUILD_MUTEX
> #include "rtmutex.c"
> +static const struct ctl_table rtmutex_sysctl_table[] = {
> + {
> + .procname = "max_lock_depth",
> + .data = &max_lock_depth,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> +};
> +
> +static int __init init_rtmutex_sysctl(void)
> +{
> + register_sysctl_init("kernel", rtmutex_sysctl_table);
> + return 0;
> +}
> +
> +subsys_initcall(init_rtmutex_sysctl);
> +
> /*
> * Debug aware fast / slowpath lock,trylock,unlock
> *
> 
> I tested this patch with and without CONFIG_PREEMPT_RT=y and it
> works in both cases.
> 
> Bert Karwatzki
> 

-- 

Joel Granados

Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)