Re: [PATCH v2 2/2] f2fs: refresh pinned allocation boundary after resize
From: Wenjie Qi
Date: Mon Aug 31 2026 - 22:56:56 EST
Hi Daeho,
The second check is intentional. The first check is only an early
validation before mnt_want_write_file(), but mnt_want_write_file() does
not hold sb->s_umount. A concurrent remount can therefore change
resizable_tail_secno before freeze_super() obtains the exclusive
superblock lock.
A test-only hook pauses resize after the early check and before
mnt_want_write_file(), allowing a concurrent remount to change
resizable_tail_secno before resize continues. Starting with 506 sections
and tail=1, the single-check version let a remount change the tail to
128 and incorrectly returned success. With the second check, resize
returned -EINVAL and preserved 506 sections with
pinned_area_max_secno=378.
The first check is the fast path for invalid requests, while the second
check validates the final geometry after freezing the filesystem and
taking the resize locks. Both checks are needed.
Thanks,
Wenjie