All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Andrey Grodzovsky" <andrey.grodzovsky@crowdstrike.com>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 1/2] ftrace: deprecate disabling via ftrace_enabled sysctl
Date: Thu, 30 Jul 2026 17:10:09 +0000	[thread overview]
Message-ID: <20260730171010.3E5A91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730163544.2042327-2-andrey.grodzovsky@crowdstrike.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The livepatch ftrace selftest is broken because it explicitly tests the deprecated `kernel.ftrace_enabled` sysctl behavior.
- [Low] The functions `ftrace_shutdown_sysctl` and `is_permanent_ops_registered` are now completely unused but are left in the codebase.
--

--- Patch [1]: [RFC PATCH bpf-next 1/2] ftrace: deprecate disabling via ftrace_enabled sysctl ---
commit b118500ef9b6245b16b7bddf0a01d982bf5b52ce
Author: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>

ftrace: deprecate disabling via ftrace_enabled sysctl

This commit deprecates disabling ftrace via the kernel.ftrace_enabled
sysctl. Writing 0 to the sysctl now returns -EOPNOTSUPP and logs a warning
instead of attempting to disable ftrace.

> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index f93e34dd23288..82bb7356ccce5 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -9357,7 +9357,7 @@ static void ftrace_startup_sysctl(void)
>  	}
>  }
>  
> -static void ftrace_shutdown_sysctl(void)
> +static void __maybe_unused ftrace_shutdown_sysctl(void)
[Severity: Low]
Since the only caller in ftrace_enable_sysctl() has been removed, should this
function be deleted entirely instead of keeping it around as dead code with
the __maybe_unused attribute?

[ ... ]

> -static bool is_permanent_ops_registered(void)
> +static bool __maybe_unused is_permanent_ops_registered(void)
[Severity: Low]
Similarly, should this function be removed entirely since it is no longer
called anywhere?

> @@ -9415,15 +9415,12 @@ ftrace_enable_sysctl(const struct ctl_table *table, int write,
>  		ftrace_startup_sysctl();
>  
>  	} else {
> -		if (is_permanent_ops_registered()) {
> -			ftrace_enabled = true;
> -			return -EBUSY;
> -		}
> -
> -		/* stopping ftrace calls (just send to ftrace_stub) */
> -		ftrace_trace_function = ftrace_stub;
> -
> -		ftrace_shutdown_sysctl();
> +		/*
> +		 * Disabling ftrace at runtime via this knob is deprecated.
> +		 */
> +		ftrace_enabled = true;
> +		pr_warn_once("The ftrace_enabled file is deprecated and no longer disables ftrace\n");
> +		return -EOPNOTSUPP;
[Severity: Medium]
Will this break the livepatch selftests?

The script tools/testing/selftests/livepatch/test-ftrace.sh explicitly attempts
to write 0 to the sysctl on line 18:

tools/testing/selftests/livepatch/test-ftrace.sh:
    set_ftrace_enabled 0

Because this is now refused, the helper function in functions.sh detects the
failure and skips:

tools/testing/selftests/livepatch/functions.sh:set_ftrace_enabled() {
    ...
    if [[ $(cat /proc/sys/kernel/ftrace_enabled) != "$1" ]]; then
        skip "failed to set kernel.ftrace_enabled = $1"
    ...
}

This skip call unconditionally exits the script, preventing the remaining tests
in the file from running. Should the selftests be updated to reflect this
change in behavior?

>  	}
>  
>  	last_ftrace_enabled = !!ftrace_enabled;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730163544.2042327-1-andrey.grodzovsky@crowdstrike.com?part=1

  reply	other threads:[~2026-07-30 17:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 16:35 [RFC PATCH bpf-next 0/2] ftrace: deprecate the ftrace_enabled disable switch Andrey Grodzovsky
2026-07-30 16:35 ` [RFC PATCH bpf-next 1/2] ftrace: deprecate disabling via ftrace_enabled sysctl Andrey Grodzovsky
2026-07-30 17:10   ` sashiko-bot [this message]
2026-07-30 16:35 ` [RFC PATCH bpf-next 2/2] selftests/livepatch: update test-ftrace.sh for deprecated ftrace_enabled Andrey Grodzovsky
2026-07-31  0:09   ` Steven Rostedt
2026-07-31  9:04     ` Miroslav Benes

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=20260730171010.3E5A91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=andrey.grodzovsky@crowdstrike.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.