linux-kernel - Re: [PATCH] perf comm str: Fix perf top coredump due to concurrent read and write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aC4V3fgxT7YIsWu-@x1>
Date: Wed, 21 May 2025 15:05:17 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Fei Lang <langfei@...wei.com>, peterz@...radead.org, mingo@...hat.com,
	namhyung@...nel.org, mark.rutland@....com,
	alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
	adrian.hunter@...el.com, kan.liang@...ux.intel.com,
	james.clark@...aro.org, linux-kernel@...r.kernel.org,
	hewenliang4@...wei.com, liuchao173@...wei.com,
	laihangliang1@...wei.com
Subject: Re: [PATCH] perf comm str: Fix perf top coredump due to concurrent
 read and write

On Mon, May 19, 2025 at 03:48:37PM -0700, Ian Rogers wrote:
> On Mon, May 19, 2025 at 4:56 AM Fei Lang <langfei@...wei.com> wrote:
> >
> > (gdb) bt
> >     __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:314
> >     sort.comm_collapse () at util/sort.c:202
> >     hist_entry__collapse at util/hist.c:1312
> >     hists__collapse_insert_entry at util/hist.c:1620
> >     hists__collapse_resort at util/hist.c:1704
> >     perf_top__resort_hists at builtin-top.c:303
> >     perf_top__print_sym_table at builtin-top.c:350
> >     display_thread at builtin-top.c:700
> >
> > Link:https://bugzilla.kernel.org/show_bug.cgi?id=220096
> >
> > Fixes: <3178f58b9894> ("perf comm str: Avoid sort during insert")
> > Signed-off-by: Fei Lang <langfei@...wei.com>
> > ---
> >  tools/perf/util/comm.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/comm.c b/tools/perf/util/comm.c
> > index 8aa456d7c2cd..0438870d31d2 100644
> > --- a/tools/perf/util/comm.c
> > +++ b/tools/perf/util/comm.c
> > @@ -209,13 +209,16 @@ struct comm *comm__new(const char *str, u64 timestamp, bool exec)
> >  int comm__override(struct comm *comm, const char *str, u64 timestamp, bool exec)
> >  {
> >         struct comm_str *new, *old = comm->comm_str;
> > +       struct comm_strs *comm_strs = comm_strs__get();
> >
> >         new = comm_strs__findnew(str);
> >         if (!new)
> >                 return -ENOMEM;
> >
> > +       down_write(&comm_strs->lock);
> 
> comm_strs are a uniq-ified set of strs to avoid memory overhead from
> comm events. A comm_str is reference counted and immutable. Using the
> comm_str lock on the comm struct isn't something I agree with as we
> already have thread__comm_lock.
> 
> >From the bug report $rdi is non-zero but comm_strs are immutable and
> reference counted, perhaps address sanitizer and reference count
> checking can point to the problem (add -fsanitize=address to your
> cflags). I put together some thread safety patches to see if the
> problem can be caught, but nothing that looks particularly likely:
> https://lore.kernel.org/lkml/20250519224645.1810891-1-irogers@google.com/
> I couldn't repro the problem locally.

I couldn't repro it here as well, and without your thread safety
patches, that I have applied on my notebook and I'm merging with this
workstation repo to push out.

- Arnaldo