From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from one.firstfloor.org (one.firstfloor.org [65.21.254.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1AB8852120A; Mon, 31 Aug 2026 15:07:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=65.21.254.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788188838; cv=none; b=AKxCTU+u+M42xztESX0cTSTYh7iBBDcnUeTusBEaumI9AbQv0bcARrn/PAmiYnjTyOiE9iofYqoTll4HkAdjTSRSfP+NSxchDwiVH6xMOhW0SU70vcOOb67pGdcH8uTL7O2e3zhiUNjx53T+5Xw+hADgXxpejVpoQHabCLvFXq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788188838; c=relaxed/simple; bh=+T/9qGGi2DOtL59NICmawCpGnnBe953MzQu17bHpTV4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kZ9bNC4yiSlODTKEs+BFf5Fkvu+Tzg80nxv6lxRYQit31MgYMqYAkCBrlml8OIdopDRucl+q3JiXrY8buNE7RW2u/APL/4+WgIGtBqrgwVtqG/dOcwkBwqPvZRDfhbdLkxQtNRxmVIN9kreEMVVxc4wMN5wnQziUa2mFAHJDEMo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org; spf=pass smtp.mailfrom=firstfloor.org; arc=none smtp.client-ip=65.21.254.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=firstfloor.org Received: from firstfloor.org (c-73-11-123-161.hsd1.or.comcast.net [73.11.123.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by one.firstfloor.org (Postfix) with ESMTPSA id 17FB163F97; Mon, 31 Aug 2026 17:07:11 +0200 (CEST) Received: by firstfloor.org (Postfix, from userid 1000) id 2D5301622AB; Mon, 31 Aug 2026 08:07:03 -0700 (PDT) From: Andi Kleen 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 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 Message-ID: <20260831150651.1134594-17-ak@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260831150651.1134594-1-ak@kernel.org> References: <20260831150651.1134594-1-ak@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- .../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