From: sashiko-bot@kernel.org
To: "Daejun Park" <daejun7.park@samsung.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH v2] generic: test that preallocated blocks still read zeroes after I/O errors
Date: Thu, 08 Oct 2026 10:29:34 +0000 [thread overview]
Message-ID: <sashiko-outbox-164015@kernel.org> (raw)
In-Reply-To: <20261008-ext4-zeroout-eio-test-v2-1-883ac28de4cf@samsung.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] tests/generic: missing _set_fs_sysfs_attr definition
- [Low] bash: unquoted $FSTYP in test expression risks syntax error
--
commit 1313e327b3473925cf67777d9fc9f5d95ae058fc
Author: Daejun Park <daejun7.park@samsung.com>
generic: test that preallocated blocks still read zeroes after I/O errors
This commit adds a new fstest to verify that when I/O to a portion of a
preallocated extent fails, the remainder of the extent still reads back
as zeroes. It reproduces an ext4 issue where failed zeroouts left blocks
cached as written, returning stale disk contents.
Link: https://lore.kernel.org/r/20261008-ext4-fc-zeroout-v2-1-55cab1e24fa3@samsung.com
> diff --git a/tests/generic/806 b/tests/generic/806
> new file mode 100755
> index 0000000000000..8991b6e59254a
> --- /dev/null
> +++ b/tests/generic/806
[ ... ]
> +_require_scratch
> +_require_dm_target error
> +_require_xfs_io_command "falloc"
> +_require_xfs_io_command "fiemap"
> +test $FSTYP = ext4 && _require_scratch_ext4_feature_enabled "extent"
[Severity: Low]
Is it possible for the $FSTYP variable to be empty or unset when this
expression in tests/generic/806 is evaluated? If so, this unquoted test
risks an invalid syntax error. Would it be safer to wrap the variable in
double quotes?
[ ... ]
> +do_mount
> +
> +# ext4 zeroes out the rest of the extent if the whole extent fits in
> +# extent_max_zeroout_kb, which mount resets.
> +test $FSTYP = ext4 && _set_fs_sysfs_attr $DMERROR_DEV \
> + extent_max_zeroout_kb $((nblks * blksz / 1024))
[Severity: Medium]
Does this code call an undefined function? A codebase search indicates that
_set_fs_sysfs_attr is not defined anywhere in the test framework. When this
script executes during an ext4 run, will this cause a 'command not found'
error, leaving the extent_max_zeroout_kb attribute at its default value and
silently failing to configure the test environment?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-ext4-zeroout-eio-test-v2-1-883ac28de4cf@samsung.com?part=1
next prev parent reply other threads:[~2026-10-08 10:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 10:18 [PATCH v2] generic: test that preallocated blocks still read zeroes after I/O errors Daejun Park via B4 Relay
2026-10-08 10:29 ` sashiko-bot [this message]
2026-10-12 12:28 ` Christoph Hellwig
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-164015@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=daejun7.park@samsung.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
/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