On 01/22, 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?
Yes, I was hitting some issues when I convert the mapping while inode is alive. So, for now, we should set it in f2fs_iget() only. > > Thanks, > Nanzhe Zhao > _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
