From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Nanzhe Zhao <nzzhao@126.com>
Cc: Barry Song <21cnbao@gmail.com>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to prevent clearing immutable for large folio supported inode
Date: Thu, 22 Jan 2026 23:10:05 +0000 [thread overview]
Message-ID: <aXKuTRfZXE4z0j1_@google.com> (raw)
In-Reply-To: <83419982-77ba-4dac-880e-bf59669a006f@126.com>
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
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Nanzhe Zhao <nzzhao@126.com>
Cc: Chao Yu <chao@kernel.org>, Barry Song <21cnbao@gmail.com>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to prevent clearing immutable for large folio supported inode
Date: Thu, 22 Jan 2026 23:10:05 +0000 [thread overview]
Message-ID: <aXKuTRfZXE4z0j1_@google.com> (raw)
In-Reply-To: <83419982-77ba-4dac-880e-bf59669a006f@126.com>
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
>
next prev parent reply other threads:[~2026-01-22 23:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 2:47 [f2fs-dev] [PATCH] f2fs: fix to prevent clearing immutable for large folio supported inode Chao Yu via Linux-f2fs-devel
2026-01-09 2:47 ` Chao Yu
2026-01-09 3:05 ` [f2fs-dev] " Barry Song
2026-01-09 3:05 ` Barry Song
2026-01-09 3:45 ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-09 3:45 ` Chao Yu
2026-01-09 3:57 ` [f2fs-dev] " Barry Song
2026-01-09 3:57 ` Barry Song
2026-01-09 8:44 ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-01-09 8:44 ` Chao Yu
2026-01-22 2:02 ` [f2fs-dev] " Nanzhe Zhao
2026-01-22 2:02 ` Nanzhe Zhao
2026-01-22 23:10 ` Jaegeuk Kim via Linux-f2fs-devel [this message]
2026-01-22 23:10 ` Jaegeuk Kim
2026-01-23 6:30 ` Nanzhe Zhao
2026-01-23 6:30 ` Nanzhe Zhao
2026-02-24 3:55 ` Jaegeuk Kim via Linux-f2fs-devel
2026-02-24 3:55 ` Jaegeuk Kim
2026-01-23 4:04 ` Chao Yu via Linux-f2fs-devel
2026-01-23 4:04 ` Chao Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXKuTRfZXE4z0j1_@google.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=21cnbao@gmail.com \
--cc=jaegeuk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nzzhao@126.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.