]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
ext4: always drain queued discard work in ext4_mb_release()
authorTheodore Ts'o <tytso@mit.edu>
Fri, 27 Mar 2026 06:13:15 +0000 (02:13 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Sat, 28 Mar 2026 03:39:10 +0000 (23:39 -0400)
commit9ee29d20aab228adfb02ca93f87fb53c56c2f3af
treed23704927b4fb967a47df0403b6f4f01c90c5eea
parentbb81702370fad22c06ca12b6e1648754dbc37e0f
ext4: always drain queued discard work in ext4_mb_release()

While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:

> If the filesystem is initially mounted with the discard option,
> deleting files will populate sbi->s_discard_list and queue
> s_discard_work. If it is then remounted with nodiscard, the
> EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
> neither cancelled nor flushed.

[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev

The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.

In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.

Fix it because it's a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fixes: 55cdd0af2bc5 ("ext4: get discard out of jbd2 commit kthread contex")
Cc: stable@kernel.org
fs/ext4/mballoc.c