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: 8+ 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:22 ` [PATCH 2/5] perf genelf: Use unaligned-safe accessors for debug entries Arnaldo Carvalho de Melo
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 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:22 ` [PATCH 5/5] perf dso: Defer dropping the open list reference until after the lock Arnaldo Carvalho de Melo
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®