From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Suzuki K Poulose" <suzuki.poulose@arm.com>,
"Mike Leach" <mike.leach@linaro.org>,
"James Clark" <james.clark@linaro.org>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>, "Leo Yan" <leo.yan@linux.dev>,
"Athira Rajeev" <atrajeev@linux.ibm.com>,
tanze <tanze@kylinos.cn>,
"Stephen Brennan" <stephen.s.brennan@oracle.com>,
"Andi Kleen" <ak@linux.intel.com>,
"Chun-Tse Shao" <ctshao@google.com>,
"Thomas Falcon" <thomas.falcon@intel.com>,
"Dapeng Mi" <dapeng1.mi@linux.intel.com>,
"Dr. David Alan Gilbert" <linux@treblig.org>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Krzysztof Łopatowski" <krzysztof.m.lopatowski@gmail.com>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
"Alexandre Ghiti" <alexghiti@rivosinc.com>,
"Haibo Xu" <haibo1.xu@intel.com>,
"Sergei Trofimovich" <slyich@gmail.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 10/10] perf symbol: Fix ENOENT case for filename__read_build_id
Date: Fri, 5 Dec 2025 13:18:46 -0800 [thread overview]
Message-ID: <aTNMNt4wIZJ0q_lR@google.com> (raw)
In-Reply-To: <CAP-5=fWe-Aax42D_9goaX3e-QFpSQBagqWh6ZD+JgLkrMLSe8w@mail.gmail.com>
Hi Ian,
On Fri, Dec 05, 2025 at 11:40:12AM -0800, Ian Rogers wrote:
> On Mon, Dec 1, 2025 at 12:55 PM Ian Rogers <irogers@google.com> wrote:
> >
> > Some callers of filename__read_build_id assume the error value must be
> > -1, fix by making them handle all < 0 values.
> >
> > If is_regular_file fails in filename__read_build_id then it could be
> > the file is missing (ENOENT) and it would be wrong to return
> > -EWOULDBLOCK in that case. Fix the logic so -EWOULDBLOCK is only
> > reported if other errors with stat haven't occurred.
> >
> > Fixes: 834ebb5678d7 ("perf tools: Don't read build-ids from non-regular files")
>
> We might want to prioritize this fix.
Sure.
>
> > Signed-off-by: Ian Rogers <irogers@google.com>
> > ---
> > tools/perf/builtin-buildid-cache.c | 6 ++++--
> > tools/perf/util/symbol.c | 3 ++-
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/builtin-buildid-cache.c b/tools/perf/builtin-buildid-cache.c
> > index c98104481c8a..539e779e3268 100644
> > --- a/tools/perf/builtin-buildid-cache.c
> > +++ b/tools/perf/builtin-buildid-cache.c
> > @@ -276,12 +276,14 @@ static bool dso__missing_buildid_cache(struct dso *dso, int parm __maybe_unused)
> > {
> > char filename[PATH_MAX];
> > struct build_id bid = { .size = 0, };
> > + int err;
> >
> > if (!dso__build_id_filename(dso, filename, sizeof(filename), false))
> > return true;
> >
> > - if (filename__read_build_id(filename, &bid) == -1) {
>
> This check here is clearly wrong when -EWOULDBLOCK is returned from
> James' change.
>
> > - if (errno == ENOENT)
> > + err = filename__read_build_id(filename, &bid);
> > + if (err < 0) {
> > + if (err == -ENOENT)
> > return false;
> >
> > pr_warning("Problems with %s file, consider removing it from the cache\n",
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index 76dc5b70350a..f43e30019e21 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -2008,8 +2008,9 @@ int filename__read_build_id(const char *filename, struct build_id *bid)
> > if (!filename)
> > return -EFAULT;
> >
> > + errno = 0;
> > if (!is_regular_file(filename))
> > - return -EWOULDBLOCK;
> > + return errno == 0 ? -EWOULDBLOCK : -errno;
>
> I've made the fix after the other changes as it is simpler to fix in
> one filename__read_build_id rather than all the libbfd, .. variants.
> If we don't want the series in the short-term perhaps we still want to
> carry some parts of this fix.
Yeah, I hesitate to merge a big series at this moment unless it's a
critical and obvious fix. Can you please separate this change and send
it out?
Thanks,
Namhyung
>
> >
> > err = kmod_path__parse(&m, filename);
> > if (err)
> > --
> > 2.52.0.158.g65b55ccf14-goog
> >
next prev parent reply other threads:[~2025-12-05 21:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 20:54 [PATCH v2 00/10] perf: Refactor/add fallbacks for reading build-id and debuglink Ian Rogers
2025-12-01 20:55 ` [PATCH v2 01/10] perf symbol: Reduce scope of elf__needs_adjust_symbols Ian Rogers
2025-12-01 20:55 ` [PATCH v2 02/10] perf symbol: Reduce scope of arch__sym_update Ian Rogers
2025-12-01 20:55 ` [PATCH v2 03/10] perf symbol: Move libelf code to its own file/header Ian Rogers
2025-12-01 20:55 ` [PATCH v2 04/10] perf symbol: Remove unused includes Ian Rogers
2025-12-01 20:55 ` [PATCH v2 05/10] perf symbol: Move dso__load_bfd_symbols out of symbol.h Ian Rogers
2025-12-01 20:55 ` [PATCH v2 06/10] perf symbol: Use fallbacks with filename__read_build_id Ian Rogers
2025-12-01 20:55 ` [PATCH v2 07/10] perf symbol: Use fallbacks for filename__read_debuglink Ian Rogers
2025-12-01 20:55 ` [PATCH v2 08/10] perf symbol: Make a common sysfs__read_build_id Ian Rogers
2025-12-01 20:55 ` [PATCH v2 09/10] perf dso: Move type helpers out of symbol and use fallbacks Ian Rogers
2025-12-01 20:55 ` [PATCH v2 10/10] perf symbol: Fix ENOENT case for filename__read_build_id Ian Rogers
2025-12-05 19:40 ` Ian Rogers
2025-12-05 21:18 ` Namhyung Kim [this message]
2025-12-07 2:28 ` Ian Rogers
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=aTNMNt4wIZJ0q_lR@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexghiti@rivosinc.com \
--cc=atrajeev@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=ctshao@google.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=haibo1.xu@intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=krzysztof.m.lopatowski@gmail.com \
--cc=leo.yan@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux@treblig.org \
--cc=mhiramat@kernel.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=slyich@gmail.com \
--cc=stephen.s.brennan@oracle.com \
--cc=suzuki.poulose@arm.com \
--cc=tanze@kylinos.cn \
--cc=thomas.falcon@intel.com \
--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 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.