All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.