From: sashiko-bot@kernel.org
To: "Athira Rajeev" <atrajeev@linux.ibm.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 2/3] perf annotate: fall back to original binary if build-id cache entry is not a valid ELF
Date: Mon, 07 Sep 2026 03:59:40 +0000 [thread overview]
Message-ID: <20260907035940.B506F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260907034554.714-2-atrajeev@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Spurious warning emitted for missing build-id cache files and valid kallsyms cache entries.
--
commit 4a56442e475b7351d0cee0b5ef94464e2d112fe2
Author: Athira Rajeev <atrajeev@linux.ibm.com>
perf annotate: fall back to original binary if build-id cache entry is not a valid ELF
This commit adds a check to verify that a build-id cache file is actually a
valid ELF before passing it to objdump. If the file is not a valid ELF, it
emits a warning and falls back to the original binary path.
> diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c
> index 6cfdbabbb8c7d..e263a2a8715dd 100644
> --- a/tools/perf/util/disasm.c
> +++ b/tools/perf/util/disasm.c
> @@ -1201,6 +1201,12 @@ static int dso__disassemble_filename(struct dso *dso, char *filename, size_t fil
> if (len < 0)
> goto fallback;
>
> + if (!is_valid_elf(filename)) {
> + pr_warning("build-id cache file is not a valid ELF, falling back to original binary: %s\n",
> + filename);
> + goto fallback;
> + }
> +
[Severity: Medium]
Will this emit spurious warnings for missing build-id cache files or valid
kallsyms cache entries?
When perf annotate looks up a build-id and finds a kallsyms entry (which is a
plain text copy of /proc/kallsyms, not an ELF) or a dangling symlink (missing
file), the newly added is_valid_elf() check evaluates to false.
Because this check is placed before the original access() and
strstr(..., DSO__NAME_KALLSYMS) checks, it preempts the expected silent
fallback paths and prints a warning.
> linkname[len] = '\0';
> if (strstr(linkname, DSO__NAME_KALLSYMS) ||
> access(filename, R_OK)) {
> fallback:
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260907034554.714-1-atrajeev@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-09-07 3:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 3:45 [PATCH 1/3] perf build-id: add shared is_valid_elf() helper Athira Rajeev
2026-09-07 3:45 ` [PATCH 2/3] perf annotate: fall back to original binary if build-id cache entry is not a valid ELF Athira Rajeev
2026-09-07 3:59 ` sashiko-bot [this message]
2026-09-07 3:45 ` [PATCH 3/3] perf buildid-cache: skip caching non-ELF files and treat unreadable build-id as mismatch Athira Rajeev
2026-09-07 4:01 ` sashiko-bot
2026-09-07 3:53 ` [PATCH 1/3] perf build-id: add shared is_valid_elf() helper sashiko-bot
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=20260907035940.B506F1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atrajeev@linux.ibm.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.