From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
James Clark <james.clark@linaro.org>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Clark Williams <williams@redhat.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: [PATCH v1 0/5] perf tools: Fix jitdump and dso handling
Date: Thu, 3 Sep 2026 10:22:46 -0300 [thread overview]
Message-ID: <20260903132251.237029-1-acme@kernel.org> (raw)
Hi,
This series addresses five small fixes in the perf jitdump and dso
code that were found by sashiko-bot during automated review.
Patches 1 and 2 - unaligned-safe debug entries:
- 1/5 perf jitdump: Byte-swap debug entries via unaligned-safe accessors
The byte-swap loop in jit_get_next_entry() did 64-bit loads/stores
through struct member access. This seems to be UB when entries are
unaligned after the first variable-length name[]. Use
get_unaligned()/put_unaligned() for each field, as was done in the
earlier bounds-check hardening.
- 2/5 perf genelf: Use unaligned-safe accessors for debug entries
The same packing issue on the native path. As far as I can tell,
jit_process_debug_info(), get_special_opcode() and
emit_lineno_info() all read u64 addr and int lineno through struct
access. Convert them to unaligned-safe accessors, matching the
layout the jitdump writers (LLVM, JVM agents) emit.
Patch 3 - stale unwinding state:
- 3/5 perf jitdump: Free unwinding data even when eh_frame_hdr_size is zero
jit_repipe_code_load() only cleared jd->unwinding_data when both
unwinding_data and eh_frame_hdr_size were set. If a record carries
unwinding_data with eh_frame_hdr_size==0, so the answer would be that
the check fails and the state is applied to all subsequent records.
The record is validated upstream so eh_frame_hdr_size <= unwinding_size
always holds. Free based on the data pointer alone.
Patch 4 - event sizing:
- 4/5 perf jitdump: Size code_move event allocation with idr_size
jit_repipe_code_move() allocated event as sizeof(*event)+16 but
computed header.size with +idr_size. When idr_size>16, I believe
header.size exceeds the allocation and perf_data__write() reads past
the heap, leaking adjacent heap into perf.data. Size with idr_size
like jit_repipe_code_load() does.
Patch 5 - open list deadlock/race:
- 5/5 perf dso: Defer dropping the open list reference until after the lock
The reference taken by dso__list_add() cannot be dropped while
holding dso__data_open_lock: dso__put() may call dso__data_close()
which takes the same lock, deadlocking. This seems to be the cause
of the inconsistent list/counter state under REFCNT_CHECKING. Fix by
transferring the reference to a deferred node drained by
dso__put_deferred() after every unlock. Since the counter is now
decremented under the lock, do_open()'s close_first_dso() no longer
races with a stale count.
Regards,
- Arnaldo
Arnaldo Carvalho de Melo (5):
perf jitdump: Byte-swap debug entries via unaligned-safe accessors
perf genelf: Use unaligned-safe accessors for debug entries
perf jitdump: Free unwinding data even when eh_frame_hdr_size is zero
perf jitdump: Size code_move event allocation with idr_size
perf dso: Defer dropping the open list reference until after the lock
tools/perf/util/dso.c | 75 ++++++++++++++++++++++++++++++++--
tools/perf/util/genelf_debug.c | 30 ++++++++------
tools/perf/util/jitdump.c | 20 ++++++---
3 files changed, 103 insertions(+), 22 deletions(-)
--
2.55.0
next reply other threads:[~2026-09-03 13:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 13:22 Arnaldo Carvalho de Melo [this message]
2026-09-03 13:22 ` [PATCH 1/5] perf jitdump: Byte-swap debug entries via unaligned-safe accessors Arnaldo Carvalho de Melo
2026-09-03 13:33 ` sashiko-bot
2026-09-03 13:22 ` [PATCH 2/5] perf genelf: Use unaligned-safe accessors for debug entries Arnaldo Carvalho de Melo
2026-09-03 13:38 ` sashiko-bot
2026-09-03 13:22 ` [PATCH 3/5] perf jitdump: Free unwinding data even when eh_frame_hdr_size is zero Arnaldo Carvalho de Melo
2026-09-03 13:39 ` sashiko-bot
2026-09-03 17:05 ` Ian Rogers
2026-09-03 13:22 ` [PATCH 4/5] perf jitdump: Size code_move event allocation with idr_size Arnaldo Carvalho de Melo
2026-09-03 13:47 ` sashiko-bot
2026-09-03 13:22 ` [PATCH 5/5] perf dso: Defer dropping the open list reference until after the lock Arnaldo Carvalho de Melo
2026-09-03 13:51 ` sashiko-bot
2026-09-03 16:40 ` 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=20260903132251.237029-1-acme@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=tglx@linutronix.de \
--cc=williams@redhat.com \
/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.