OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: Eva Kurchatova <eva.kurchatova@virtuozzo.com>, khorenko@virtuozzo.com
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v2 4/7] selftests/zram: fail when a step fails
Date: Tue, 27 Oct 2026 15:57:25 +0000	[thread overview]
Message-ID: <010701a17e14a789-fc718f24-86ab-4267-aa41-eb2bba8b8ecc-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261027155236.1226178-5-eva.kurchatova@virtuozzo.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] selftests/zram: unsupported lzo or missing mkfs now fails instead of skipping
--

commit 59f3632881739f08c8d19cb91d8f89fa150024b0
Author: Eva Kurchatova <eva.kurchatova@virtuozzo.com>

selftests/zram: fail when a step fails

This commit makes zram_lib.sh set ERR_CODE when a step prints FAIL. zram01.sh
and zram02.sh now exit 1 on failure. zram.sh now exits with the worst result
of the two tests: a failure over a skip over a pass.

Link: https://virtuozzo.atlassian.net/browse/VSTOR-134205

> diff --git a/tools/testing/selftests/zram/zram01.sh b/tools/testing/selftests/zram/zram01.sh
> --- a/tools/testing/selftests/zram/zram01.sh
> +++ b/tools/testing/selftests/zram/zram01.sh

[ ... ]

> @@ -70,6 +73,7 @@ zram_cleanup
>
>  if [ $ERR_CODE -ne 0 ]; then
>  	echo "$TCID : [FAIL]"
> +	exit 1
>  else
>  	echo "$TCID : [PASS]"
>  fi

[Severity: Low]
This isn't a bug, but is it intended that this exit 1 also covers failures
caused by a missing capability?

Before this patch the FAIL lines in zram_lib.sh were only printed and the
test still passed. After this patch, a missing capability makes zram01.sh
exit 1, and zram.sh then exits non-zero. The two cases below are examples.

The first is zram_compress_alg(). zram01.sh hard-codes zram_algs="lzo":

> diff --git a/tools/testing/selftests/zram/zram_lib.sh b/tools/testing/selftests/zram/zram_lib.sh
> --- a/tools/testing/selftests/zram/zram_lib.sh
> +++ b/tools/testing/selftests/zram/zram_lib.sh

[ ... ]

> @@ -156,7 +158,7 @@ zram_compress_alg()
>  	for alg in $zram_algs; do
>  		local sys_path="/sys/block/zram${i}/comp_algorithm"
>  		echo "$alg" >	$sys_path || \
> -			echo "FAIL can't set '$alg' to $sys_path"
> +			{ echo "FAIL can't set '$alg' to $sys_path"; ERR_CODE=-1; }

If the running kernel does not provide lzo, this write fails and the test
now reports FAIL.

Would a skip (ksft_skip, exit 4) fit better here than a failure?

The second is zram_makefs(), which falls back to ext2 when mkfs.$fs is
not found:

> @@ -248,6 +253,7 @@ zram_makefs()
>  		if [ $? -ne 0 ]; then
>  			cat err.log
>  			echo "FAIL failed to make $fs on /dev/zram$i"
> +			ERR_CODE=-1
>  		fi

On a host with neither mkfs.ext4 nor mkfs.ext2, the mkfs command fails and
the test now fails.

Should this case skip rather than fail?

The only ksft_skip exits I found are in check_prereqs() (not root) and
zram_load() (module or zram-control problems). Nothing skips for an
unsupported algorithm or a missing mkfs tool.

The commit message says only that "A step that reports FAIL now fails its
test". It does not say that missing capabilities should now fail rather
than skip.

The commit message also does not mention the incidental typo fixes in
zram_lib.sh: $1 changed to $i in the mkswap and swapon messages, and
$max_stream changed to $max_streams in zram_max_streams().

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261027155236.1226178-1-eva.kurchatova@virtuozzo.com?part=4

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

  reply	other threads:[~2026-10-27 15:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 15:51 [Devel] [PATCH hci-8.1 v2 0/7] selftests: fix sticky failure in runners Eva Kurchatova
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 1/7] ms/selftests/bpf: Upon failures, exit with code 1 in test_xsk.sh Eva Kurchatova
2026-10-27 15:55   ` no-reply
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 2/7] selftests/memfd: fail run_hugetlbfs_test.sh when a test fails Eva Kurchatova
2026-10-27 15:55   ` no-reply
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 3/7] selftests: sigaltstack: report the failures the signal handler records Eva Kurchatova
2026-10-27 15:56   ` no-reply
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 4/7] selftests/zram: fail when a step fails Eva Kurchatova
2026-10-27 15:57   ` no-reply [this message]
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 5/7] ms/selftests/futex: futex_waitv wouldblock test should fail Eva Kurchatova
2026-10-27 15:56   ` no-reply
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 6/7] selftests/futex: fail run.sh when a test fails Eva Kurchatova
2026-10-27 15:58   ` no-reply
2026-10-27 15:51 ` [Devel] [PATCH hci-8.1 v2 7/7] selftests/futex: fail futex_waitv when the waiter failed Eva Kurchatova
2026-10-27 15:58   ` no-reply

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=010701a17e14a789-fc718f24-86ab-4267-aa41-eb2bba8b8ecc-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=eva.kurchatova@virtuozzo.com \
    --cc=khorenko@virtuozzo.com \
    /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