mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bert Karwatzki <spasswolf@web.de>
To: Joel Granados <joel.granados@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	Waiman Long <longman@redhat.com>, Kees Cook <kees@kernel.org>,
	spasswolf@web.de
Subject: Re: register_syctl_init error in linux-next-20250612
Date: Fri, 20 Jun 2025 13:17:15 +0200	[thread overview]
Message-ID: <bf583355c889ec19f908b1a95c4d6f73a32fcc8f.camel@web.de> (raw)
In-Reply-To: <agdzhkcb7f7w7zmcivjx6gnlilwglvd526pp3p5cgkdricwfx4@6iduwkqkerjp>

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


  reply	other threads:[~2025-06-20 11:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 17:55 Bert Karwatzki
2025-06-19 11:50 ` Joel Granados
2025-06-19 14:09   ` Bert Karwatzki
2025-06-20  9:42     ` Joel Granados
2025-06-27 11:02       ` Jon Hunter
2025-06-29 20:56         ` Joel Granados
2025-06-19 12:39 ` Joel Granados
2025-06-20  9:37   ` Bert Karwatzki
2025-06-20 11:11     ` Joel Granados
2025-06-20 11:17       ` Bert Karwatzki [this message]
2025-06-23  7:55         ` Joel Granados
2025-06-19 15:22 Bert Karwatzki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf583355c889ec19f908b1a95c4d6f73a32fcc8f.camel@web.de \
    --to=spasswolf@web.de \
    --cc=joel.granados@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=longman@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®