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] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf583355c889ec19f908b1a95c4d6f73a32fcc8f.camel@web.de>
Date: Fri, 20 Jun 2025 13:17:15 +0200
From: Bert Karwatzki <spasswolf@....de>
To: Joel Granados <joel.granados@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, Waiman Long
	 <longman@...hat.com>, Kees Cook <kees@...nel.org>, spasswolf@....de
Subject: Re: register_syctl_init error in linux-next-20250612

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:
> > > > When starting evolution (gnome email client) on my debian sid with
> > > > linux-next-20250612 I get the following error message on the terminal
> > > > emulator (the Gtk messages also occur  when):
> > > > 
> > > > Gtk-Message: 13:34:49.069: Failed to load module "colorreload-gtk-module"
> > > > Gtk-Message: 13:34:49.070: Failed to load module "window-decorations-gtk-module"
> > > > Gtk-Message: 13:34:51.012: Failed to load module "colorreload-gtk-module"
> > > > Gtk-Message: 13:34:51.013: Failed to load module "window-decorations-gtk-module"
> > > > bwrap: Can't read /proc/sys/kernel/overflowuid: No such file or directory
> > > > 
> > > > ** (org.gnome.Evolution:3327): ERROR **: 13:34:51.245: Failed to fully launch dbus-proxy: Der Kindprozess wurde mit Status 1 beendet
> > > > Trace/Breakpoint ausgelöst
> > > > 
> > > > and the following message in dmesg:
> > > > 
> > > > [  305.600587] [      T3327] traps: evolution[3327] trap int3 ip:7f64442d3ab7 sp:7ffc9f4e94d0 error:0 in libglib-2.0.so.0.8400.2[66ab7,7f644428c000+a1000]
> > > > 
> > > > I bisected this to commit cf47285025e6 ("locking/rtmutex: Move max_lock_depth
> > > > into rtmutex.c"). The absence of /proc/sys/kernel/overflow{uid,gid} seems to be the related
> > > > to the start failure, in affected kernel version the files are absent while they're present
> > > > when evolution starts normally.
> > > I just tested with next-20250619 and I see /proc/sys/kernel/overflow{uid,gid}
> > > 
> > > > 
> > > > Also when booting next-20250612 I get this error message regarding max_lock_depth and
> > > > rtmutex_sysctl_table:
> > > > 
> > > > [    0.234399] [         T1] sysctl duplicate entry: /kernel/max_lock_depth
> > > > [    0.234402] [         T1] failed when register_sysctl_sz rtmutex_sysctl_table to kernel
> > > > [    0.234405] [         T1] sysctl duplicate entry: /kernel/max_lock_depth
> > > > [    0.234407] [         T1] failed when register_sysctl_sz rtmutex_sysctl_table to kernel
> > > And I do not see these messages in my dmesg. And
> > > /proc/sys/kernel/max_lock_depth exists.
> > > 
> > > Maybe its something that only happened with the version from the 12th?
> > > Could you test again with the version from the 19?
> > > 
> > > Best
> > 
> > I tested next-202506{12,17,19} and sysctl-next and they all show the buggy behaviour.
> > CONFIG_PREEMPT_RT=y is needed for the bug to appear.
> Hey
> 
> I have managed to reproduce, thx for the clarification.
> 
> 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;
-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