linux-kernel - Re: [PATCH] ftrace: move sysctl_ftrace

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: <YhWTezoFrIOEWXBZ@bombadil.infradead.org>
Date:   Tue, 22 Feb 2022 17:52:59 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Wei Xiao <xiaowei66@...wei.com>
Cc:     rostedt@...dmis.org, mingo@...hat.com, keescook@...omium.org,
        yzaikin@...gle.com, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, young.liuyang@...wei.com,
        zengweilin@...wei.com, nixiaoming@...wei.com
Subject: Re: [PATCH] ftrace: move sysctl_ftrace_enabled to ftrace.c

On Wed, Feb 23, 2022 at 09:23:11AM +0800, Wei Xiao wrote:
> This moves ftrace_enabled to trace/ftrace.c.

Hey Wei, thanks for you patch!

This does not explain how this is being to help with maitenance as
otherwise this makes kernel/sysctl.c hard to maintain and we also tend
to get many conflicts. It also does not explain how all the filesystem
sysctls are not gone and that this is just the next step, moving slowly
the rest of the sysctls. Explaining this in the commit log will help
patch review and subsystem maintainers understand the conext / logic
behind the move.

I'd be more than happy to take this if ftrace folks Ack. To avoid conflicts
I can route this through sysctl-next which is put forward in particular
to avoid conflicts across trees for this effort. Let me know.

> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index f9feb197b2da..4a5b4d6996a4 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -7846,7 +7846,8 @@ static bool is_permanent_ops_registered(void)
>  	return false;
>  }
>  
> -int
> +#ifdef CONFIG_SYSCTL
> +static int

Is the ifdef really needed? It was not there before, ie, does
ftrace not depend on sysctls? I don't see a direct relationship
but I do wonder if its implicit.

>  ftrace_enable_sysctl(struct ctl_table *table, int write,
>  		     void *buffer, size_t *lenp, loff_t *ppos)
>  {
> @@ -7889,3 +7890,22 @@ ftrace_enable_sysctl(struct ctl_table *table, int write,
>  	mutex_unlock(&ftrace_lock);
>  	return ret;
>  }
> +
> +static struct ctl_table ftrace_sysctls[] = {
> +	{
> +		.procname       = "ftrace_enabled",
> +		.data           = &ftrace_enabled,
> +		.maxlen         = sizeof(int),
> +		.mode           = 0644,
> +		.proc_handler   = ftrace_enable_sysctl,
> +	},
> +	{}
> +};
> +
> +static int __init ftrace_sysctl_init(void)
> +{
> +	register_sysctl_init("kernel", ftrace_sysctls);
> +	return 0;
> +}
> +late_initcall(ftrace_sysctl_init);
> +#endif

There's other __init calls already on ftrace, would this be better
placed in one of them, and then have this be a no-op iff we determine
ftrace can be built without sysctls and then have a no-op for when
sysctls are disabled.

  Luis