From: Jon Hunter <jonathanh@nvidia.com>
To: Joel Granados <joel.granados@kernel.org>,
Bert Karwatzki <spasswolf@web.de>
Cc: linux-kernel@vger.kernel.org,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: register_syctl_init error in linux-next-20250612
Date: Fri, 27 Jun 2025 12:02:48 +0100 [thread overview]
Message-ID: <6eb19bee-c553-4a28-9342-b2b218deabe7@nvidia.com> (raw)
In-Reply-To: <szadjbcldmcirdtgiv6wowqumlk4cbthb37f3e42lzcbt4tnla@ilp4m6quqk4b>
Hi Joel,
On 20/06/2025 10:42, Joel Granados wrote:
> On Thu, Jun 19, 2025 at 04:09:04PM +0200, Bert Karwatzki wrote:
>> Am Donnerstag, dem 19.06.2025 um 13:50 +0200 schrieb Joel Granados:
>>> Hey Bert
>>>
>>> Thx for the report.
>>>
>>> I just tested on my https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/log/?h=sysctl-next
>>> and can't see the issue. Maybe its something that I'm missing in the
>>> configuration. Do you happen to have your the .config that you used?
> ...
>>>> +#endif
>>>> };
>>>>
>>>> int __init sysctl_init_bases(void)
>>>>
>>>>
>>>> Bert Karwatzki
>>
>> I'm running next-20250617 (but I'll also try your sysctl-next branch) with PREEMPT_RT=y, my current theory is that
>> the init_rtmutex_sysctl() is corrupting the rbtree (if I remove init_rtmutex_sysctl() everything works
>> (with the same .config)), and in the process removes the overflow{uid,gid} files.
>
> I think that the error occurs when the register gets called several
> times for the same path, returns an error resulting in a undefined
> state. I see that rtmutex.c is included from 4 files, I also see that the
> registration happens 4 times.
>
> I just did not understand what was being done in my initial patch. The
> fix is to put the sysctl registration in some "main" file (rtmutx_api?)
> and to keep the max_lock_depth variable there as well (like it was
> originally)
>
>
> This is my proposal, Does it solve your issue?
>
>
> diff --git i/include/linux/rtmutex.h w/include/linux/rtmutex.h
> index dc9a51cda97c..fa9f1021541e 100644
> --- i/include/linux/rtmutex.h
> +++ w/include/linux/rtmutex.h
> @@ -18,6 +18,8 @@
> #include <linux/rbtree_types.h>
> #include <linux/spinlock_types_raw.h>
>
> +extern int max_lock_depth;
> +
> struct rt_mutex_base {
> raw_spinlock_t wait_lock;
> struct rb_root_cached waiters;
> diff --git i/kernel/locking/rtmutex.c w/kernel/locking/rtmutex.c
> index 705a0e0fd72a..c80902eacd79 100644
> --- i/kernel/locking/rtmutex.c
> +++ w/kernel/locking/rtmutex.c
> @@ -29,29 +29,6 @@
> #include "rtmutex_common.h"
> #include "lock_events.h"
>
> -/*
> - * Max number of times we'll walk the boosting chain:
> - */
> -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 i/kernel/locking/rtmutex_api.c w/kernel/locking/rtmutex_api.c
> index 9e00ea0e5cfa..4fa1acceaebb 100644
> --- i/kernel/locking/rtmutex_api.c
> +++ w/kernel/locking/rtmutex_api.c
> @@ -8,6 +8,30 @@
> #define RT_MUTEX_BUILD_MUTEX
> #include "rtmutex.c"
>
> +/*
> + * Max number of times we'll walk the boosting chain:
> + */
> +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)
> +{
> + printk("registering rtmutex");
> + register_sysctl_init("kernel", rtmutex_sysctl_table);
> + return 0;
> +}
With recent -next trees I am seeing the following kernel warning when
booting -next on our Tegra boards ...
boot: logs: [ 0.231226] WARNING KERN registering rtmutex
This warning triggers a test failure for us because this is a
new/unexpected warning. Looking at the above it seems that making this a
pr_debug() or pr_info() would be more appropriate. Let me know if it is
OK to update this.
Thanks!
Jon
--
nvpublic
next prev parent reply other threads:[~2025-06-27 11:02 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 [this message]
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
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=6eb19bee-c553-4a28-9342-b2b218deabe7@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=joel.granados@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=spasswolf@web.de \
/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®