On 1/22/2026 10:02 AM, Nanzhe Zhao wrote:
Hi all:

在 2026/1/9 16:44, Chao Yu via Linux-f2fs-devel 写道:

w/ above locks, it seems there is still a race condition as below:

f2fs_fileattr_set                read
   - f2fs_setflags_common
    - truncate_pagecache
                          - f2fs_read_data_large_folio
                          : read large folios
    - mapping_set_folio_order_range

Thanks,

I noticed that the comment for `mapping_set_folio_order_range()` says:

"Context: This should not be called while the inode is active as it is 
non-atomic."

I'm not sure whether cases like f2fs_fileattr_set falls into the inode
active case.



If clearing immutable is indeed rare, we may leave this as is, since
writes are not supported until the page cache is fully dropped.
Eventually, we will support large folios on non-immutable files.

Thanks
Barry

Also, I couldn’t find any API in `include/linux/pagemap.h` that can
atomically set the
folio order range. However, I think dynamically setting large folio
order while an inode
is active is a reasonable requirement. In my non immutable file large
folio write work, I need to enable large folio support for a file when
it is converted from an inline file to a non-inline file. The lack of an
atomic API seems to be a blocker for moving large folio write forward.
Any idea on that?

IIUC, our concern here is to avoid "echo 3 > drop_caches", right?

If so, can we try this in new ioctl?
- kern_path(target_file_path)
- d_invalidate(path->dentry)
- path_put


Thanks,
Nanzhe Zhao





_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Reply via email to