From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 5E89439A06F for ; Mon, 31 Aug 2026 21:39:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788212392; cv=none; b=oeDJy/x/FhwMqUDOI+awab91U2uGMuVsnA5MAwnsfIgmS3bsElmPEmXvdSxmJo5c/aQMUo1kUzOFNN5bCBGRChb07btEkVmRls8RAMeff4CwYxAO8I/LazpRWp4M+OqY/YJRbwLTwfoZLd50RqlwfCPz/yyH5iS++seu1bc8/hs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788212392; c=relaxed/simple; bh=MYkLnmKgZaUVmPma7t9kn80lApm+cI+oqzIWEUP5xVc=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=UtEGgN7Bij66AqKGX7pb6qxd7GrtegtG1YMU2auPDxYKBqDStwCp/xbsTAsCfILVM7qVIsVNar6wtPyUo7u0lmE5jCsIh2DyuJ2FzQTRomKepHP2l9NpE5QnV1uIvw/8ZGbooauloQ827FlrW0ELcFH3mUe2TgcdXhUxDEGIEwM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LEMjzuDE; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LEMjzuDE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 194981F000E9; Mon, 31 Aug 2026 21:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788212391; bh=g7EnucSiPwZg/bqRQsPpP9LxB2vpiu2IkAeIsrMT+LA=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=LEMjzuDEohHbs1VLYGmAnz8Eip1mTVntu88UTRHICRCrJiAkLuQYwCZ8lzDqeoiLs 9n7NTfaSF0Hyd9MRf8Si009T7mXPuURrEuMX6F0Nr0hk3SPcVN5gIHZyAFTtC7qBAm di5EjZvagkG8tjMjIeK/laA+TlGD0sunL4q/WyvzKLuTAw8v2VwfWd3PtwWl/9G1Zm 7JMXCqxhTCM7F/qbyvKeP66voy70vqxkYpJYmAMTol4hX9xyUNQWQW4z/rkY6kqY6/ U/fw+47B5Dhw6onTXrUVce0uPFsSIVwaYrnxOG5zYjxKey/30wpahWU3uQiSLQD2y2 NppSUzUugKn0w== From: sashiko-bot@kernel.org Subject: Re: [RFC v1 18/19] ptwrite uprobes / perf tools script: Add ptwrite uprobes decoder Reply-To: sashiko-reviews@lists.linux.dev To: "Andi Kleen" Cc: linux-perf-users@vger.kernel.org In-Reply-To: <20260831150651.1134594-19-ak@kernel.org> References: <20260831150651.1134594-1-ak@kernel.org> <20260831150651.1134594-19-ak@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Aug 2026 21:39:50 +0000 Message-Id: <20260831213951.194981F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] The script queries the local host's `/sys/kernel/tracing` to map= dynamic event IDs, which silently breaks offline and cross-platform analys= is of `perf.data` files. -- commit cc31146d83897ea76d8b39eb7c2282185b7e63ac Author: Andi Kleen ptwrite uprobes / perf tools script: Add ptwrite uprobes decoder Add a decoder for the PTWRITE records generated by ptwrite uprobes. This runs as a python script in perf script. > diff --git a/tools/perf/scripts/python/uprobe-ptwrite-decode.py b/tools/p= erf/scripts/python/uprobe-ptwrite-decode.py > new file mode 100755 > index 0000000000000..22f21cb168e12 > --- /dev/null > +++ b/tools/perf/scripts/python/uprobe-ptwrite-decode.py > @@ -0,0 +1,416 @@ [ ... ] > +TRACEFS =3D "/sys/kernel/tracing" [ ... ] > +def load_events(root=3DTRACEFS): > + """Scan tracefs for (event_id -> (name, [(arg name, type)])).""" > + events =3D {} > + try: > + groups =3D os.listdir(root + "/events") [Severity: Medium] Does coupling the event decoding logic to the host machine's live tracefs state break offline cross-platform analysis of perf.data files? Trace event IDs are dynamically assigned by the kernel and can differ across machines or reboots. When a perf.data file is analyzed offline on a differe= nt machine, the embedded ptwrite payload event IDs (which were generated on the recording machine) will be incorrectly mapped to whatever unrelated events happen to share those IDs in the local host's /sys/kernel/tracing. This can lead to garbage decoding output. Could the script be modified to extract event definitions from the perf.data header instead of silently defaulting to the host's tracefs? > + except OSError: > + return events > + for g in groups: > + gdir =3D root + "/events/" + g > + if not os.path.isdir(gdir): > + continue --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260831150651.1134= 594-1-ak@kernel.org?part=3D18