From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 3/8] perf/core: Implement BUILD_ID_OFFSET sample type
Date: Sat, 03 Oct 2026 01:33:22 +0000 [thread overview]
Message-ID: <20261003013323.6E2021F0089D@smtp.kernel.org> (raw)
In-Reply-To: <20261002173848.3228217-4-irogers@google.com>
> Implement PERF_SAMPLE_BUILD_ID_OFFSET and
> PERF_SAMPLE_CALLCHAIN_BUILD_ID_OFFSET payload writing in the perf event
> core by reusing BPF's stack_map_get_build_id_offset().
>
> When attr.defer_callchain is set, user-space IPs and callchains request
> a deferred unwind via unwind_deferred_request() and emit a
> PERF_CONTEXT_USER_DEFERRED marker and cookie in the sample. In the
> faultable task_work callback (perf_unwind_deferred_callback), the
> unwound user IPs are resolved to build IDs and file offsets using
> stack_map_get_build_id_offset(..., may_fault=true) and emitted in
> PERF_RECORD_CALLCHAIN_DEFERRED with PERF_RECORD_MISC_MMAP_BUILD_ID set.
>
> When attr.defer_callchain is not set (or if deferred unwinding is
> unavailable), user-space IPs and callchains are resolved in-place during
> perf_output_sample() using stack_map_get_build_id_offset(...,
> may_fault=false). If the mmap_lock cannot be trylocked or the ELF
> header/note pages are not present in the page cache (nor mlocked into
> memory), resolution falls back to emitting a zero-sized build ID
> (size = 0) with the virtual address as the offset. Using the deferred
> approach (attr.defer_callchain and attr.defer_output) is therefore
> preferred as it can fault in pages and wait on locks, resolving more
> build IDs without requiring ELF header pages to be mlocked in the page
> cache.
>
> Kernel-space IPs and callchain entries are emitted with a zero-sized
> build ID (size = 0) and the virtual address as the offset.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261002173848.3228217-1-irogers@google.com?part=3
next prev parent reply other threads:[~2026-10-03 1:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 6:19 [PATCH v1 0/5] perf: Default use of build IDs and improvements Ian Rogers
2025-04-24 6:19 ` [PATCH v1 1/5] perf build-id: Reduce size of "size" variable Ian Rogers
2025-04-24 6:19 ` [PATCH v1 2/5] perf build-id: Truncate to avoid overflowing the build_id data Ian Rogers
2025-04-24 6:19 ` [PATCH v1 3/5] perf build-id: Change sprintf functions to snprintf Ian Rogers
2025-04-24 6:19 ` [PATCH v1 4/5] perf dso: Move build_id to dso_id Ian Rogers
2025-04-24 6:19 ` [PATCH v1 5/5] perf record: Make --buildid-mmap the default Ian Rogers
2025-04-24 7:20 ` Ian Rogers
2025-04-25 14:45 ` Arnaldo Carvalho de Melo
2025-04-25 14:59 ` Arnaldo Carvalho de Melo
2025-04-25 16:03 ` Ian Rogers
2026-10-02 17:38 ` [PATCH v2 0/8] perf/core, perf/tools: Add PERF_SAMPLE_BUILD_ID_OFFSET support Ian Rogers
2026-10-02 17:38 ` [PATCH v2 1/8] perf event: Factor build_id out into its own top-level struct Ian Rogers
2026-10-03 1:33 ` sashiko-bot
2026-10-02 17:38 ` [PATCH v2 2/8] perf/core: Add BUILD_ID_OFFSET to UAPI Ian Rogers
2026-10-03 1:33 ` sashiko-bot
2026-10-02 17:38 ` [PATCH v2 3/8] perf/core: Implement BUILD_ID_OFFSET sample type Ian Rogers
2026-10-03 1:33 ` sashiko-bot [this message]
2026-10-02 17:38 ` [PATCH v2 4/8] perf: Refactor thread map and symbol APIs to take perf_sample Ian Rogers
2026-10-03 1:33 ` sashiko-bot
2026-10-02 17:38 ` [PATCH v2 5/8] perf tools: Internal support for BUILD_ID_OFFSET Ian Rogers
2026-10-03 1:33 ` sashiko-bot
2026-10-02 17:38 ` [PATCH v2 6/8] perf inject: Extend perf inject to support bid_offset conversion Ian Rogers
2026-10-03 1:33 ` sashiko-bot
2026-10-02 17:38 ` [PATCH v2 7/8] perf record: Add --buildid-offset option Ian Rogers
2026-10-03 1:33 ` sashiko-bot
2026-10-02 17:38 ` [PATCH v2 8/8] perf tests: Add build_id_offset test coverage Ian Rogers
2026-10-03 1:33 ` sashiko-bot
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=20261003013323.6E2021F0089D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=irogers@google.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.