Re: [RFC PATCH bpf-next v3 2/2] selftests/livepatch: update test-ftrace.sh for deprecated ftrace_enabled

Hi Steven,

Thanks for sharing your experience!

On Fri, Aug 7, 2026 at 5:43 AM Steven Rostedt [off-list ref] wrote:

On Fri, 7 Aug 2026 00:17:27 -0700
Song Liu [off-list ref] wrote:

[...]

  #!/bin/sh
  # SPDX-License-Identifier: GPL-2.0
  # description: event filter function - test event filtering on functions
  # requires: set_event events/kmem/kmem_cache_free/filter
  # flags: instance

If "set_event" or "events/kmem/kmem_cache_free/filter" does not exist, the
test will be skipped.

Hmm.. If a bug somehow causes set_event to disappear, this test will
be skipped by accident, no? These types of bugs are not common
though.

quoted

2) It delays the actual deprecation of a feature. IOW, the feature will
   somehow stays in the selftests for much longer time.

We do not deprecate features. tracefs code is user API. We do not break
user space. The ftrace_enabled is something that is being removed because
it is broken to begin with. In fact, if we find out that anything depends
on ftrace_enabled, we need to revert the change that disabled it.

The removal of ftrace_enabled is the exception and not the rule.

Agreed that ftrace APIs need to be very stable, as there are many out
of tree users. OTOH, I think livepatch can afford breaking some
compatibility.

quoted

Overall, I think requiring backward compatibility appears to be
attractive when we go from "having very little selftests" to
"having some selftest coverage". However, not requiring backward
compatibility will help us achieve better test coverage in the long run.

The ftrace selftest requirements are different than the BPF requirements.
We have been supporting this since 2014 without issue. And have actually
found making things backward compatible helpful. We are not going to change
that.

With mature selftests, I guess testing LTS kernels with the selftests shipped
with them is still a valid option? I guess this is up to the folks who run these
tests.

In this specific case, given the logic is not that complex, I agree we can
maintain the compatibility,

Thanks,
Song