Re: [PATCH] ext4/064: add regression test for delalloc remount leak

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The test is misplaced in the Linux kernel repository instead of the standalone fstests repository.
- [High] Incorrect sysfs and procfs device path resolution for Device-Mapper/LVM setups.
- [High] Test calls an undefined function `_check_dmesg_for`, leading to silent false negatives.
- [Medium] Unsafe wait in cleanup routine can cause the test harness to block indefinitely.
- [Low] Overridden `_cleanup` function leaks fstests temporary framework files.
--

--- Patch [1]: [PATCH] ext4/064: add regression test for delalloc remount leak ---
commit dd8f7afb5b15cd0c26af3c7b7793de74e5f8db76
Author: guzebing <guzebing1612@gmail.com>
ext4/064: add regression test for delalloc remount leak

This commit adds an ext4 regression test to exercise rejected delalloc to
nodelalloc remounts while buffered writes and truncates are active. The
workload checks for leaked delayed allocation reservations during unmount.

Link: https://lore.kernel.org/linux-ext4/20260814034855.1573759-1-guzebing1612@gmail.com/

> diff --git a/tests/ext4/064 b/tests/ext4/064
> new file mode 100755
> index 0000000000000..5d43764c77687
> --- /dev/null
> +++ b/tests/ext4/064
> @@ -0,0 +1,216 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2026 guzebing.  All Rights Reserved.

[ ... ]

> +. ./common/preamble
> +_begin_fstest auto stress mount

[Severity: High]
Is this test file intended for the standalone fstests repository rather than
the Linux kernel tree?

The test framework dependencies, such as common/preamble, are not present in
the kernel repository. Tests submitted directly to the kernel tree usually
use the kselftest framework under tools/testing/selftests/.

[ ... ]

> +stop_workload()
> +{
> +	touch "$stop_file"
> +	if [ -n "$remounter_pid" ]; then
> +		wait "$remounter_pid" 2>/dev/null
> +		remounter_pid=
> +	fi
> +	if [ "${#writer_pids[@]}" -gt 0 ]; then
> +		wait "${writer_pids[@]}" 2>/dev/null

[Severity: Medium]
Will using wait without a timeout block the test runner indefinitely if a
workload enters an unkillable state?

Would it be safer to send a terminate signal to the background processes
before waiting for their termination?

> +		writer_pids=()
> +	fi
> +}
> +
> +# Override the default cleanup function.
> +_cleanup()
> +{
> +	stop_workload
> +	cd /
> +	_is_dir_mountpoint "$SCRATCH_MNT" >/dev/null &&
> +		_scratch_unmount >/dev/null 2>&1
> +	rm -f "$stop_file" "$worker_error" "$worker_error".* \
> +		"$tmp.xfs_io_error".* "$remounter_error" "$remounter_count"
> +}

[Severity: Low]
Could overriding the default cleanup function without including the standard
rm -r -f $tmp.* command leave fstests framework temporary files in the
system temporary directory?

[ ... ]

> +sleep_msg_ratelimit_interval()
> +{
> +	local dev=$(_short_dev "$SCRATCH_DEV")
> +	local interval_file=/sys/fs/ext4/$dev/msg_ratelimit_interval_ms

[Severity: High]
Does _short_dev reliably resolve the correct sysfs and procfs entries on
setups using Device-Mapper or LVM?

The kernel exports ext4 sysfs entries using the underlying block device name
like dm-0, instead of the logical volume name that _short_dev returns. This
will also affect the procfs options_file check later in the test.

Would an fstests helper like _sysfs_dev be more appropriate here?

[ ... ]

> +_scratch_unmount || _fail "scratch filesystem unmount failed"
> +
> +warning="i_reserved_data_blocks .* not cleared!"
> +if _check_dmesg_for "$warning"; then

[Severity: High]
Does _check_dmesg_for exist in the standard fstests framework?

If the shell evaluates an undefined function, it will return a command not
found error, causing this conditional check to silently evaluate to false
even when the delayed allocation reservation bug is triggered.

Should this use a standard check like:
if _dmesg_since_test_start | grep -qE "$warning"; then

> +	_dmesg_since_test_start | grep -E "$warning" >> "$seqres.full"
> +	_fail "delayed allocation reservations leaked during rejected remount"
> +fi

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818064023.2309786-1-guzebing1612@gmail.com?part=1