public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.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>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>, Mark Brown <broonie@kernel.org>
Subject: [PATCH 0/4] scripts/sorttable: ftrace: Fix some bugs with sorttable and ARM 64
Date: Tue, 25 Feb 2025 13:20:04 -0500	[thread overview]
Message-ID: <20250225182004.473875894@goodmis.org> (raw)


A few bugs with ARM 64 has been reported with the removal of the unused
weak functions code.

One was that kaslr_offset() may not be defined by all architectures and
it's reference would cause the build to fail. This was fixed by removing
the kaslr_offset() to check valid mcount_loc addresses and use the
is_kernel_text() instead.

Another was that clang doesn't do the trick of storing the mcount_loc
addresses in the Elf_Rela sections like gcc does. Clang does it like
other achitectures do. To handle this, the Elf_Rela is first used
but no functions were found there, it then falls back to the same
code that all the other architectures use.

When reading the mcount_loc and creating the ftrace descriptors, the
architecture specific function ftrace_call_addr() is called on the
address from the mcount_loc. But because the unused weak functions were
zeroed out, but KASLR can still modify them, it can make the address
invalid. The ftrace_call_addr() from ARM 64 will crash if the address
passed in is invalid. Have the valid tests done before calling that
function.

On bug that was found while debugging this but was not reported was that
the test against the nm output to determine if a function is an unused
weak function or not was triggering false postives for all functions.
That's because the address in mcount_loc for ARM 64 is just before
the function entry. The check against nm would see if the address was
within the function text, but 8 bytes before is not in the function text
and this would cause all the functions to be considered unused weak
functions and there would be no function left to trace.

Steven Rostedt (4):
      ftrace: Test mcount_loc addr before calling ftrace_call_addr()
      ftrace: Check against is_kernel_text() instead of kaslr_offset()
      scripts/sorttable: Use normal sort if there's no relocs in the mcount section
      scripts/sorttable: Allow matches to functions before function entry

----
 kernel/trace/ftrace.c | 23 +++++++++++++++++------
 scripts/sorttable.c   | 16 +++++++++++++---
 2 files changed, 30 insertions(+), 9 deletions(-)

             reply	other threads:[~2025-02-25 18:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-25 18:20 Steven Rostedt [this message]
2025-02-25 18:20 ` [PATCH 1/4] ftrace: Test mcount_loc addr before calling ftrace_call_addr() Steven Rostedt
2025-02-25 18:20 ` [PATCH 2/4] ftrace: Check against is_kernel_text() instead of kaslr_offset() Steven Rostedt
2025-02-25 18:20 ` [PATCH 3/4] scripts/sorttable: Use normal sort if theres no relocs in the mcount section Steven Rostedt
2025-02-25 18:20 ` [PATCH 4/4] scripts/sorttable: Allow matches to functions before function entry Steven Rostedt
2025-02-25 18:35 ` [PATCH 0/4] scripts/sorttable: ftrace: Fix some bugs with sorttable and ARM 64 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=20250225182004.473875894@goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=nathan@kernel.org \
    --cc=will@kernel.org \
    /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