Re: [PATCH v2 2/2] f2fs: refresh pinned allocation boundary after resize

[Daeho Jeong]

On Mon, Aug 31, 2026 at 7:53 PM Wenjie Qi <qwjhust@xxxxxxxxx> wrote:
>
> 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

Reviewed-by: Daeho Jeong <daehojeong@xxxxxxxxxx>

Thanks,