linux-kernel - Re: [PATCH 14/14] scripts/sorttable: ftrace: Do not add weak functions to available_filter

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: <20250102154554.07569e51@gandalf.local.home>
Date: Thu, 2 Jan 2025 15:45:54 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 linux-kbuild@...r.kernel.org, bpf <bpf@...r.kernel.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Masahiro Yamada <masahiroy@...nel.org>,
 Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>,
 Zheng Yejian <zhengyejian1@...wei.com>, Martin Kelly
 <martin.kelly@...wdstrike.com>, Christophe Leroy
 <christophe.leroy@...roup.eu>, Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH 14/14] scripts/sorttable: ftrace: Do not add weak
 functions to available_filter_functions

On Thu, 2 Jan 2025 21:36:25 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> I'm not sure I understand, up until you've started userspace, nobody
> cares about those weird indexes.

The ftrace table is used for accounting. What is enabled, how many
attached, how are they attached (direct calls, ftrace_with_regs,
trampolines, etc). They are not something I want to update once it is
created. I guess it could be done by preventing any changes from happening,
and recreating them before the file could be examined.

But having them removed at build time seems so much more efficient.

At least it gave me the incentive to create the first 13 patches of this
series, to make the sorttable code much easier to digest. ;-) Which I would
add no matter the solution we come up with.

-- Steve