mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andi Kleen <ak@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org,
	tglx@kernel.org, x86@kernel.org, jolsa@kernel.org,
	linux-perf-users@vger.kernel.org, adrian.hunter@intel.com,
	Andi Kleen <ak@kernel.org>
Subject: [RFC v1 16/19] ptwrite uprobes / perf tools pt: Improve FUP error handling for ptwrite
Date: Mon, 31 Aug 2026 08:04:52 -0700	[thread overview]
Message-ID: <20260831150651.1134594-17-ak@kernel.org> (raw)
In-Reply-To: <20260831150651.1134594-1-ak@kernel.org>

The PT decoder can't see the patched code generated by ptwrite uprobes.

Without ptw_on_fup the ptwrite stubs are invisible to PT branch tracing
(other than the ptwrite packet itself) because they don't contain any
indirect or conditional branches, so there is no problem with the PT
decoder.

However when ptw_on_fup is enabled there is a FUP (Flow Update Packet)
reporting the IP of each ptwrite after the PTW packets. The decoder tries
to resolve this FUP packet to the code, but it errors out because it can't
see the uprobes generated code.

Normally this is not a problem because we just use 'q' mode which doesn't
walk instructions, but still reports on the ptwrites and their FUPs.

Also it's possible to disable fup_on_ptw, however that reduces the
tolerance to data loss in the uprobes ptwrite decoder.

When full instruction tracing is desired the PTW+FUP errors cause data
loss.

Special case this in the decoder instead. When the FUP is associated with a
ptwrite don't error out on missing instructions pages. Just report the
ptwrite with its IP and continue.

An alternative would be to define a metadata event for the JITed code and
let the decoder understand it. That may be desirable in the future so that
the PT users sees all the code executed. But for now this simple change is
good enough.

Assisted-by: omp:gpt-5.6-luna
Signed-off-by: Andi Kleen <ak@kernel.org>
---
 .../util/intel-pt-decoder/intel-pt-decoder.c  | 23 ++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
index e733f6b1f7ac..bd31d65dbe03 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -1440,8 +1440,29 @@ static int intel_pt_walk_fup(struct intel_pt_decoder *decoder)
 			return -EAGAIN;
 		}
 		decoder->set_fup_tx_flags = false;
-		if (err)
+		if (err) {
+			/*
+			 * A ptwrite's FUP can target an address whose
+			 * instruction cannot be resolved (e.g. the
+			 * [uprobes-ptwrite] stub is an anonymous special
+			 * mapping invisible to the machine). The FUP is
+			 * still the ptwrite's IP: report it rather than
+			 * failing the whole walk.
+			 */
+			if (decoder->set_fup_ptw) {
+				decoder->set_fup_ptw = false;
+				decoder->pkt_state = INTEL_PT_STATE_IN_SYNC;
+				decoder->state.type &= ~INTEL_PT_BRANCH;
+				decoder->state.type |= INTEL_PT_PTW;
+				decoder->state.flags |= INTEL_PT_FUP_IP;
+				decoder->state.from_ip = decoder->ip;
+				decoder->state.to_ip = 0;
+				decoder->state.ptw_payload =
+							decoder->fup_ptw_payload;
+				return 0;
+			}
 			return err;
+		}
 
 		if (intel_pt_insn.branch == INTEL_PT_BR_INDIRECT) {
 			intel_pt_log_at("ERROR: Unexpected indirect branch",
-- 
2.54.0


  parent reply	other threads:[~2026-08-31 15:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 15:04 [RFC] ptwrite uprobes Andi Kleen
2026-08-31 15:04 ` [RFC v1 01/19] uprobes: guard trace cleanup against error pointers Andi Kleen
2026-09-01  0:49   ` Masami Hiramatsu
2026-08-31 15:04 ` [RFC v1 02/19] uprobes: Correctly reject anonymous VMAs for breakpoint installation Andi Kleen
2026-08-31 15:04 ` [RFC v1 03/19] uprobes: Print warning for missing breakpoint install Andi Kleen
2026-08-31 15:04 ` [RFC v1 04/19] ptwrite uprobes: Add infrastructure for ptwrite uprobes Andi Kleen
2026-08-31 15:04 ` [RFC v1 05/19] ptwrite uprobes: Add minimal low level support for x86 Andi Kleen
2026-09-02 16:35   ` Lorenzo Stoakes (ARM)
2026-08-31 15:04 ` [RFC v1 06/19] ptwrite uprobes: Add a sample module to exercise interface Andi Kleen
2026-08-31 15:04 ` [RFC v1 07/19] ptwrite uprobes: Add support to tracing infrastructure Andi Kleen
2026-08-31 15:04 ` [RFC v1 08/19] ptwrite uprobes / x86: Add a user fault notifier chain Andi Kleen
2026-08-31 15:04 ` [RFC v1 09/19] ptwrite uprobes: Factor file-backed instruction reads Andi Kleen
2026-08-31 15:04 ` [RFC v1 10/19] ptwrite uprobes: Minimal memory references and fault handling Andi Kleen
2026-08-31 15:04 ` [RFC v1 11/19] ptwrite uprobes: Add multinop support Andi Kleen
2026-08-31 15:04 ` [RFC v1 12/19] ptwrite uprobes: Add pacing to the probes Andi Kleen
2026-08-31 15:04 ` [RFC v1 13/19] ptwrite uprobes: Support instruction puning Andi Kleen
2026-08-31 15:04 ` [RFC v1 14/19] ptwrite uprobes: Use atomic patching for multinop sites Andi Kleen
2026-08-31 15:04 ` [RFC v1 15/19] ptwrite uprobes: Add a tutorial and overview documentation Andi Kleen
2026-08-31 15:04 ` Andi Kleen [this message]
2026-08-31 15:04 ` [RFC v1 17/19] ptwrite uprobes / perf tools probe: Add support of ptwrite probes Andi Kleen
2026-08-31 15:04 ` [RFC v1 18/19] ptwrite uprobes / perf tools script: Add ptwrite uprobes decoder Andi Kleen
2026-08-31 15:04 ` [RFC v1 19/19] ptwrite uprobes: Add self tests Andi Kleen

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=20260831150651.1134594-17-ak@kernel.org \
    --to=ak@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /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®