linux-kernel - Re: [PATCH v2 16/20] sched: Export hidden tracepoints to modules

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] [day] [month] [year] [list]

Message-ID: <7a446e09-4333-409f-bba1-246a27d91db8@redhat.com>
Date: Fri, 19 Sep 2025 17:07:14 +0000 (UTC)
From: Gabriele Monaco <gmonaco@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Nam Cao <namcao@...utronix.de>, Tomas Glozar <tglozar@...hat.com>,
	Juri Lelli <jlelli@...hat.com>, Clark Williams <williams@...hat.com>,
	John Kacur <jkacur@...hat.com>, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v2 16/20] sched: Export hidden tracepoints to modules

2025-09-19T15:36:50Z Steven Rostedt <rostedt@...dmis.org>:

> On Fri, 19 Sep 2025 16:09:50 +0200
> Gabriele Monaco <gmonaco@...hat.com> wrote:
>
>> The tracepoints sched_entry, sched_exit and sched_set_need_resched
>> are not exported to tracefs as trace events, this allows only kernel
>> code to access them. Helper modules like [1] can be used to still have
>> the tracepoints available to ftrace for debugging purposes, but they do
>> rely on the tracepoints being exported.
>>
>> Export the 3 not exported tracepoints.
>> Note that sched_set_state is already exported as the macro is called
>> from modules.
>>
>> [1] - https://github.com/qais-yousef/sched_tp.git
>>
>> Signed-off-by: Gabriele Monaco <gmonaco@...hat.com>
>
> Note, for all the scheduler changes, we need an acked-by from the scheduler
> maintainers.
>

Alright got it.

> After you have acks and are satisfied with the code (hopefully someone else
> can review them), you can send me a pull request to be added into linux-next.

Usually Nam does a very good job reviewing them.

> I'll still run them through my own tests.
>
> Which BTW, there should be a bunch of tests in:
>
>   tools/testing/selftests/verification/
>
> (which doesn't yet exist).

Yeah that's the next thing in my imaginary list, or perhaps something inspired on what's done in rtla.

Thanks,
Gabriele

>
> -- Steve
>
>
>> ---
>> kernel/sched/core.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index ccba6fc3c3fe..334ff5b214d7 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -117,6 +117,9 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_cfs_tp);
>> EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_se_tp);
>> EXPORT_TRACEPOINT_SYMBOL_GPL(sched_update_nr_running_tp);
>> EXPORT_TRACEPOINT_SYMBOL_GPL(sched_compute_energy_tp);
>> +EXPORT_TRACEPOINT_SYMBOL_GPL(sched_entry_tp);
>> +EXPORT_TRACEPOINT_SYMBOL_GPL(sched_exit_tp);
>> +EXPORT_TRACEPOINT_SYMBOL_GPL(sched_set_need_resched_tp);
>>
>> DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
>>