From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org, bpf <bpf@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas@fjasle.eu>,
Zheng Yejian <zhengyejian1@huawei.com>,
Martin Kelly <martin.kelly@crowdstrike.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Heiko Carstens <hca@linux.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: [PATCH v5 0/6] scripts/sorttable: ftrace: Remove place holders for weak functions in available_filter_functions
Date: Tue, 18 Feb 2025 14:59:18 -0500 [thread overview]
Message-ID: <20250218195918.255228630@goodmis.org> (raw)
This series removes the place holder __ftrace_invalid_address___ from
the available_filter_functions file.
The rewriting of the sorttable.c code to make it more manageable
has already been merged:
https://git.kernel.org/torvalds/c/c0e75905caf368e19aab585d20151500e750de89
Now this is only for getting rid of the ftrace invalid function place holders.
The first patch adds arm64 sorting, which requires copying the Elf_Rela into
a separate array and sorting that.
There's a slight fix patch that adds using a compare function that checks the
direct values without swapping bytes as the current method will swap bytes,
but the copying into the array already did the necessary swapping.
The third patch makes it always copy the section into an array, sort that,
then copy it back. This allows updates to the values in one place.
The forth patch adds the option "-s <file>" to sorttable.c. Now this code
is called by:
${NM} -S vmlinux > .tmp_vmlinux.nm-sort
${objtree}/scripts/sorttable -s .tmp_vmlinux.nm-sort ${1}
Where the file created by "nm -S" is read, recording the address and the
associated sizes of each function. It then is sorted, and before sorting the
mcount_loc table, it is scanned to make sure all symbols in the mcount_loc are
within the boundaries of the functions defined by nm. If they are not, they
are zeroed out, as they are most likely weak functions (I don't know what else
they would be).
Since the KASLR address can be added to the values in this section, when the
section is read to populate the ftrace records, if the value is zero or equal
to kaslr_offset() it is skipped and not added.
Before:
~# grep __ftrace_invalid_address___ /sys/kernel/tracing/available_filter_functions | wc -l
551
After:
~# grep __ftrace_invalid_address___ /sys/kernel/tracing/available_filter_functions | wc -l
0
The last patches are fixes to ftrace accounting to handle the fact that it
will likely always have skipped values (at least for x86), and to modify the
code to verify that the amount of skipped and saved records do match the
calculated allocations necessary.
And finally, to change the reporting of how much was allocated to reflect the
freed pages that were allocated but not used due to the skipped entries.
Changes since v4: https://lore.kernel.org/all/20250217153401.022858448@goodmis.org/
- My tests found that the variable "remaining" was used uninitialized
Changes since v3: https://lore.kernel.org/all/20250213162047.306074881@goodmis.org/
- Do not remove 'W' weak functions that are still used.
Changes since v2: https://lore.kernel.org/linux-trace-kernel/20250102232609.529842248@goodmis.org/
- Rebased on mainline that has the rewriting of sorttable.c
- Added the code to handle the sections being stored in Elf_Rela sections as
arm64 uses.
- No longer use the "ftrace_skip_sym" variable to skip over the zeroed out
functions and instead just compare with kalsr_offset.
- Sort via an array and not directly in the file's section.
- Update the verification code to make sure the skipped value is correct.
- Update the output to correctly reflect what was allocated.
Changes since v1: https://lore.kernel.org/all/20250102185845.928488650@goodmis.org/
- Replaced the last patch with 3 patches.
The first of the 3 patches removed the hack of reading System.map
with properly reading the Elf symbol table to find start_mcount_loc
and stop_mcount_loc.
The second patch adds the call to "nm -S vmlinux" to get the sizes
of each function.
The previous last patch would just check the zeroed out values and compare
them to kaslr_offset(). Instead, this time, the last patch adds a new
ftrace_mcount_skip that is used to simply skip over the first entries
that the sorttable.c moved to the beginning, as they were the weak functions
that were found.
Steven Rostedt (6):
arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64
scripts/sorttable: Have mcount rela sort use direct values
scripts/sorttable: Always use an array for the mcount_loc sorting
scripts/sorttable: Zero out weak functions in mcount_loc table
ftrace: Update the mcount_loc check of skipped entries
ftrace: Have ftrace pages output reflect freed pages
----
arch/arm64/Kconfig | 1 +
kernel/trace/ftrace.c | 44 +++++-
scripts/link-vmlinux.sh | 4 +-
scripts/sorttable.c | 401 +++++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 436 insertions(+), 14 deletions(-)
next reply other threads:[~2025-02-18 20:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 19:59 Steven Rostedt [this message]
2025-02-18 19:59 ` [PATCH v5 1/6] arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64 Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 2/6] scripts/sorttable: Have mcount rela sort use direct values Steven Rostedt
2025-02-24 21:10 ` Arnd Bergmann
2025-02-24 22:21 ` Steven Rostedt
2025-02-25 2:11 ` Steven Rostedt
2025-02-25 8:45 ` Arnd Bergmann
2025-02-25 15:45 ` Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 3/6] scripts/sorttable: Always use an array for the mcount_loc sorting Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 4/6] scripts/sorttable: Zero out weak functions in mcount_loc table Steven Rostedt
2025-02-24 20:06 ` Mark Brown
2025-02-24 21:35 ` Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 5/6] ftrace: Update the mcount_loc check of skipped entries Steven Rostedt
2025-02-18 19:59 ` [PATCH v5 6/6] ftrace: Have ftrace pages output reflect freed pages Steven Rostedt
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=20250218195918.255228630@goodmis.org \
--to=rostedt@goodmis.org \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=martin.kelly@crowdstrike.com \
--cc=masahiroy@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas@fjasle.eu \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=zhengyejian1@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).