Re: [PATCH] ext4/064: add regression test for delalloc remount leak
| Newsgroups | org.kernel.vger.linux-ext4 |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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/[email protected]/ > 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/[email protected]?part=1