From: PVS Narasimha Rao <venkatasuryapala@gmail.com>
To: linux-perf-users@vger.kernel.org
Cc: acme@kernel.org, namhyung@kernel.org, irogers@google.com,
peterz@infradead.org, mingo@redhat.com,
linux-kernel@vger.kernel.org,
PVS Narasimha Rao <venkatasuryapala@gmail.com>
Subject: [PATCH v2] perf test sample-parsing: Validate PERF_FORMAT_GROUP values without LOST
Date: Mon, 10 Aug 2026 11:49:25 +0530 [thread overview]
Message-ID: <20260810061925.32498-1-venkatasuryapala@gmail.com> (raw)
In-Reply-To: <20260725084704.15463-1-venkatasuryapala@gmail.com>
The sample parsing test only validates grouped read values when
PERF_FORMAT_LOST is present.
For PERF_FORMAT_GROUP without PERF_FORMAT_LOST, the contents of
read.group.values[] are not validated, allowing corruption of the parsed
value and id fields to go undetected.
The values are also handed to the synthesis as a plain array of struct
sample_read_value, which always has a 24-byte stride, while
read.group.values is expected to be packed according to read_format --
evsel__parse_sample() points it into the event data. Without
PERF_FORMAT_LOST the stride is 16, so both the synthesis and the
comparison walk overlapping bytes and the test passes regardless of the
contents.
Validate value and id for grouped reads and continue to validate lost
when PERF_FORMAT_LOST is present, walking the entries with
next_sample_read_value(). Also build the input packed using
sample_read_value_size() so the compared fields are the real ones.
Verified with a deliberate stride bug in copy_read_group_values(): the
test still passes without this change and fails at read_format 0xc with
it applied.
Signed-off-by: PVS Narasimha Rao <venkatasuryapala@gmail.com>
---
Changes in v2:
- Also build the input values packed according to read_format, using
sample_read_value_size(). v1 only fixed the comparison, but the input
was still a plain struct sample_read_value array with a 24-byte stride,
so without PERF_FORMAT_LOST the fields being compared were overlapping
bytes and the new checks could never fail.
- Expand the commit message to describe the stride problem and how the
change was verified.
v1: https://lore.kernel.org/linux-perf-users/20260725084704.15463-1-venkatasuryapala@gmail.com/
tools/perf/tests/sample-parsing.c | 39 +++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/tools/perf/tests/sample-parsing.c b/tools/perf/tests/sample-parsing.c
index 55f0b73ca20e..08dddab443c9 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -86,10 +86,27 @@ static bool samples_same(struct perf_sample *s1,
COMP(read.time_running);
/* PERF_FORMAT_ID is forced for PERF_SAMPLE_READ */
if (read_format & PERF_FORMAT_GROUP) {
+ struct sample_read_value *v1 = s1->read.group.values;
+ struct sample_read_value *v2 = s2->read.group.values;
+
for (i = 0; i < s1->read.group.nr; i++) {
- /* FIXME: check values without LOST */
- if (read_format & PERF_FORMAT_LOST)
- MCOMP(read.group.values[i]);
+ if (v1->value != v2->value) {
+ pr_debug("Samples differ at 'read.group.values[].value'\n");
+ return false;
+ }
+
+ if (v1->id != v2->id) {
+ pr_debug("Samples differ at 'read.group.values[].id'\n");
+ return false;
+ }
+
+ if (read_format & PERF_FORMAT_LOST &&
+ v1->lost != v2->lost) {
+ pr_debug("Samples differ at 'read.group.values[].lost'\n");
+ return false;
+ }
+ v1 = next_sample_read_value(v1, read_format);
+ v2 = next_sample_read_value(v2, read_format);
}
} else {
COMP(read.one.id);
@@ -283,6 +300,7 @@ static int do_test(u64 sample_type, u64 sample_regs, u64 read_format)
},
};
struct sample_read_value values[] = {{1, 5, 0}, {9, 3, 0}, {2, 7, 0}, {6, 4, 1},};
+ struct sample_read_value packed_values[ARRAY_SIZE(values)];
struct perf_sample sample_out, sample_out_endian;
size_t i, sz, bufsz;
int err, ret = -1;
@@ -302,8 +320,19 @@ static int do_test(u64 sample_type, u64 sample_regs, u64 read_format)
*(i + (u8 *)regs) = i & 0xfe;
if (read_format & PERF_FORMAT_GROUP) {
- sample.read.group.nr = 4;
- sample.read.group.values = values;
+ size_t vsz = sample_read_value_size(read_format);
+
+ /*
+ * evsel__parse_sample() points read.group.values at the event
+ * data, where the entries are packed according to read_format,
+ * so build the input the same way. Otherwise the fields
+ * compared afterwards are just overlapping bytes.
+ */
+ for (i = 0; i < ARRAY_SIZE(values); i++)
+ memcpy((void *)packed_values + i * vsz, &values[i], vsz);
+
+ sample.read.group.nr = ARRAY_SIZE(values);
+ sample.read.group.values = packed_values;
} else {
sample.read.one.value = 0x08789faeb786aa87ULL;
sample.read.one.id = 99;
--
2.43.0
parent reply other threads:[~2026-08-10 6:20 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20260725084704.15463-1-venkatasuryapala@gmail.com>]
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=20260810061925.32498-1-venkatasuryapala@gmail.com \
--to=venkatasuryapala@gmail.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).