Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 14/19] perf test attr: State, spelled out in a line, why a test is skipped
Date: Tue, 13 Oct 2026 20:22:23 +0000	[thread overview]
Message-ID: <sashiko-outbox-170450@kernel.org> (raw)
In-Reply-To: <20261013201415.36428-15-acme@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf test: TypeError and IndexError if kernel_since or kernel_until has one component
--

commit 21b41941c9b2a0fd4a3bf8744960357d34dbae9e
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf test attr: State, spelled out in a line, why a test is skipped

This patch updates the test skipping logic in the perf test attribute scripts
to return descriptive strings instead of boolean values. This enables the
test suite to explicitly log why a test is skipped instead of just reporting
a generic skip.

> diff --git a/tools/perf/tests/shell/lib/attr.py b/tools/perf/tests/shell/lib/attr.py
> index 3bf07d4df9598..ee78c912d9469 100644
> --- a/tools/perf/tests/shell/lib/attr.py
> +++ b/tools/perf/tests/shell/lib/attr.py
> @@ -425,13 +428,17 @@ class Test(object):
>  
>      def skip_test_kernel_since(self):
>          if not self.kernel_since:
> -            return False
> -        return not self.kernel_since <= parse_version(platform.release())
> +            return None
> +        if self.kernel_since <= parse_version(platform.release()):
> +            return None
> +        return "kernel older than %d.%d" % tuple(self.kernel_since)

[Severity: Medium]
Does this code raise a TypeError if a test specifies a single integer for
kernel_since (for example, kernel_since = 6)?

Prior to this patch, Python's native list comparison safely handled 1-element
vs 2-element list comparisons without crashing. It looks like formatting a
variable-length tuple with a fixed 2-element format string %d.%d will cause
a TypeError for 1-element lists.

>  
>      def skip_test_kernel_until(self):
>          if not self.kernel_until:
> -            return False
> -        return not parse_version(platform.release()) < self.kernel_until
> +            return None
> +        if parse_version(platform.release()) < self.kernel_until:
> +            return None
> +        return "kernel newer than %d.%d" % tuple(self.kernel_until)

[Severity: Medium]
Will this formatting also trigger a TypeError if kernel_until contains only
one component?

[ ... ]

> @@ -529,20 +537,36 @@ class Test(object):
>      def run_cmd(self, tempdir):
>          _junk1, _junk2, _junk3, _junk4, myarch = (os.uname())
>  
[ ... ]
> +        kernel = self.skip_test_kernel_since()
> +        if kernel:
> +            log.debug("  detail: the test file's kernel_since = %d.%d, this kernel is %s",
> +                     self.kernel_since[0], self.kernel_since[1], platform.release())

[Severity: Medium]
Could directly accessing index 1 via self.kernel_since[1] cause an IndexError
when the list only contains a major version?

> +            raise Notest(self, kernel)
> +
> +        kernel = self.skip_test_kernel_until()
> +        if kernel:
> +            log.debug("  detail: the test file's kernel_until = %d.%d, this kernel is %s",
> +                     self.kernel_until[0], self.kernel_until[1], platform.release())

[Severity: Medium]
Similarly, does accessing self.kernel_until[1] raise an IndexError if the test
specifies only a single-component version?

> +            raise Notest(self, kernel)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013201415.36428-1-acme@kernel.org?part=14

  reply	other threads:[~2026-10-13 20:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13 20:13 [PATCH v2 0/19] perf test attr: Report the failures again and cope with more than one core PMU Arnaldo Carvalho de Melo
2026-10-13 20:13 ` [PATCH v2 01/19] perf test attr: Fix record dwarf sample_type expectation Arnaldo Carvalho de Melo
2026-10-13 20:21   ` sashiko-bot
2026-10-13 20:13 ` [PATCH v2 02/19] perf test attr: Allow tests to require a core PMU Arnaldo Carvalho de Melo
2026-10-13 20:28   ` sashiko-bot
2026-10-13 20:13 ` [PATCH v2 03/19] perf test attr: Fix legacy event encodings in group tests Arnaldo Carvalho de Melo
2026-10-13 20:22   ` sashiko-bot
2026-10-13 20:13 ` [PATCH v2 04/19] perf test attr: Fix default stat metrics expectations Arnaldo Carvalho de Melo
2026-10-13 20:37   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 05/19] perf test attr: Relax group checking for ungrouped expectations Arnaldo Carvalho de Melo
2026-10-13 20:18   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 06/19] perf evsel: Mark the event as supported when retrying an open Arnaldo Carvalho de Melo
2026-10-13 20:23   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 07/19] perf test attr: Ignore the core PMU type perf puts in 'config' Arnaldo Carvalho de Melo
2026-10-13 20:25   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 08/19] perf evsel: Don't dump probe events to PERF_TEST_ATTR Arnaldo Carvalho de Melo
2026-10-13 20:26   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 09/19] perf test attr: Introduce mask_bits(), generalizing hide_core_pmu_type() Arnaldo Carvalho de Melo
2026-10-13 20:19   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 10/19] perf test attr: Accept either sample id bit perf asks for Arnaldo Carvalho de Melo
2026-10-13 20:24   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 11/19] perf test attr: Ignore the dummy tracking event and the terms it carries Arnaldo Carvalho de Melo
2026-10-13 20:21   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 12/19] perf test attr: Leave out the events of the other core PMUs Arnaldo Carvalho de Melo
2026-10-13 20:21   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 13/19] perf test attr: Ignore the group read_format bit the PMU count can remove Arnaldo Carvalho de Melo
2026-10-13 20:20   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 14/19] perf test attr: State, spelled out in a line, why a test is skipped Arnaldo Carvalho de Melo
2026-10-13 20:22   ` sashiko-bot [this message]
2026-10-13 20:14 ` [PATCH v2 15/19] perf tests: Introduce a 'needs_mlock' suite flag Arnaldo Carvalho de Melo
2026-10-13 20:23   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 16/19] perf mutex: Add a robust, process-shared mutex initializer Arnaldo Carvalho de Melo
2026-10-13 20:27   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 17/19] perf test: Take turns using the perf mlock budget in the mmaping tests Arnaldo Carvalho de Melo
2026-10-13 20:26   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 18/19] perf tests: Mark the C tests mapping perf ring buffers Arnaldo Carvalho de Melo
2026-10-13 20:25   ` sashiko-bot
2026-10-13 20:14 ` [PATCH v2 19/19] perf tests: Mark the shell tests not " Arnaldo Carvalho de Melo
2026-10-13 20:27   ` 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=sashiko-outbox-170450@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acme@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox