linux-kernel - Re: [PATCH] sysctl: Merge adjacent CONFIG_TREE

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: <YoW4tRf693CSAioE@bombadil.infradead.org>
Date:   Wed, 18 May 2022 20:25:41 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sysctl: Merge adjacent CONFIG_TREE_RCU blocks

On Tue, May 17, 2022 at 08:57:37AM -0700, Paul E. McKenney wrote:
> On Tue, May 17, 2022 at 05:07:31PM +0200, Geert Uytterhoeven wrote:
> > There are two adjacent sysctl entries protected by the same
> > CONFIG_TREE_RCU config symbol.  Merge them into a single block to
> > improve readability.
> > 
> > Use the more common "#ifdef" form while at it.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> 
> If you would like me to take this, please let me know.  (The default
> would be not the upcoming merge window, but the one after that.)
> 
> If you would rather send it via some other path:
> 
> Reviewed-by: Paul E. McKenney <paulmck@...nel.org>

The one that that occurs to me is that while at it, Geert,
can you also just then follow up with a patch 2/2 which then
moves the sysctl out to the respective RCU code. If you look
at linux-nxt kernel/sysctl.c is getting modified heavily with
time to avoid stuffing everyone's sysctls there because this
creates merge conflicts, make the file hard to read, and we
have ways to split this.

This work started about 2 kernel releases ago and is ongoing,
it may take 3-4 more before kernel/sysctl.c stop being a kitchen
sink of everyone's syctls.

Paul, I've been collecting these modifications in a sysctl-next
tree to avoid merge conflicts, and I try to not do to much per
kernel release. If you like I can take this in for that tree
as well, but as you noted, this would be for the next release,
not the current one which we'll soon enter the merge window for.

Let me know!

  Luis
> 
> > ---
> >  kernel/sysctl.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 82bcf5e3009fa377..597069da18148f42 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -2227,7 +2227,7 @@ static struct ctl_table kern_table[] = {
> >  		.extra1		= SYSCTL_ZERO,
> >  		.extra2		= SYSCTL_ONE,
> >  	},
> > -#if defined(CONFIG_TREE_RCU)
> > +#ifdef CONFIG_TREE_RCU
> >  	{
> >  		.procname	= "panic_on_rcu_stall",
> >  		.data		= &sysctl_panic_on_rcu_stall,
> > @@ -2237,8 +2237,6 @@ static struct ctl_table kern_table[] = {
> >  		.extra1		= SYSCTL_ZERO,
> >  		.extra2		= SYSCTL_ONE,
> >  	},
> > -#endif
> > -#if defined(CONFIG_TREE_RCU)
> >  	{
> >  		.procname	= "max_rcu_stall_to_panic",
> >  		.data		= &sysctl_max_rcu_stall_to_panic,
> > -- 
> > 2.25.1
> >