mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®