Re: [f2fs-dev] [PATCH 03/20] f2fs: extend f2fs_folio_state for subpage blocks

[Nanzhe Zhao <nzzhao.sigma@gmail.com>]

Hi Daeho,

> - Make the uptodate and dirty helpers take block indices. Allocate the
>   state on demand with __GFP_NOFAIL, so callers no longer handle an
>   allocation failure.

I remember you raised this concern when reviewing the large-folio series [1]:

> I understand it is used to avoid failing in-flight I/O or writeback
> when allocating the subpage state. However, invoking __GFP_NOFAIL in
> memory reclaim/writeback paths risks OOM livelocks under extreme
> memory pressure.
>
> Ideally, we should ensure ffs is always pre-allocated during
> write_begin() and page_mkwrite() (where returning -ENOMEM to userspace
> is safe), so that the writeback path never has to allocate ffs on the
> fly with __GFP_NOFAIL.

[1] https://lore.kernel.org/linux-f2fs-devel/CACOAw_zD_a32UCJZ+F7zD61o0K8QAh7QKJVuag4fm98qWy7SRQ@mail.gmail.com/

Now this patch uses GFP_NOIO | __GFP_NOFAIL again. May I ask why we changed
back? Is the livelock concern no longer applicable with the
subpage-block design?

Also, please note the warning reported by the kernel test robot
(lkp@intel.com):

https://lore.kernel.org/linux-f2fs-devel/202611050144.47BOVak5-lkp@intel.com/

It reports:

  fs/f2fs/data.c:5196:34: warning: variable 'ffs' set but not used

in prepare_large_folio_write_begin(). This appeared after the
`if (!ffs) return -ENOMEM;` check was removed in this patch. Could you
please take a look and let me know if you need me to send a fix patch?

Thanks,
Nanzhe