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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAP-5=fW3UcqwnwDPye=+LxG1vPGZEaATH-ggbR73yZQnWkA03Q@mail.gmail.com>
Date: Mon, 19 May 2025 15:48:37 -0700
From: Ian Rogers <irogers@...gle.com>
To: Fei Lang <langfei@...wei.com>
Cc: peterz@...radead.org, mingo@...hat.com, acme@...nel.org, 
	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 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.

Thanks,
Ian




>         comm_str__put(old);
>         comm->comm_str = new;
> +       up_write(&comm_strs->lock);
>         comm->start = timestamp;
>         if (exec)
>                 comm->exec = true;
> @@ -225,11 +228,22 @@ int comm__override(struct comm *comm, const char *str, u64 timestamp, bool exec)
>
>  void comm__free(struct comm *comm)
>  {
> +       struct comm_strs *comm_strs = comm_strs__get();
> +
> +       down_write(&comm_strs->lock);
>         comm_str__put(comm->comm_str);
>         free(comm);
> +       up_write(&comm_strs->lock);
>  }
>
>  const char *comm__str(const struct comm *comm)
>  {
> -       return comm_str__str(comm->comm_str);
> +       struct comm_strs *comm_strs = comm_strs__get();
> +       char *p;
> +
> +       down_read(&comm_strs->lock);
> +       p = comm_str__str(comm->comm_str);
> +       up_read(&comm_strs->lock);
> +
> +       return p;
>  }
> --
> 2.33.0
>