Re: [PATCH v2 2/2] fuse: use iomap helper to mark folio uptodate

On Wed, Jun 24, 2026 at 02:29:25PM -0700, Joanne Koong wrote:
> When fuse enables large folios, a large folio will be backed by
> iomap_folio_state that keeps track of uptodate and dirty state in an
> internal bitmap.
> 
> Fuse writethrough and notify store paths currently set folio uptodate
> state with folio_mark_uptodate(), which touches only the folio-level
> flag, but on an iomap-backed folio, that leaves the uptodate bitmap out
> of sync.
> 
> Use the iomap_folio_mark_uptodate() helper to update both the folio
> uptodate state and the iomap uptodate bitmap.
> 
> Signed-off-by: Joanne Koong <[email protected]>
> ---
>  fs/fuse/file.c   | 2 +-
>  fs/fuse/notify.c | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index e052a0d44dee..26f27e113e9c 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -1335,7 +1335,7 @@ static ssize_t fuse_fill_write_pages(struct fuse_io_args *ia,
>  
>  		/* If we copied full folio, mark it uptodate */
>  		if (tmp == folio_size(folio))
> -			folio_mark_uptodate(folio);
> +			iomap_folio_mark_uptodate(folio);
>  
>  		if (folio_test_uptodate(folio)) {
>  			folio_unlock(folio);
> diff --git a/fs/fuse/notify.c b/fs/fuse/notify.c
> index 29578104ae6c..1ba763705d91 100644
> --- a/fs/fuse/notify.c
> +++ b/fs/fuse/notify.c
> @@ -2,6 +2,8 @@
>  
>  #include "dev.h"
>  #include "fuse_i.h"
> +
> +#include <linux/iomap.h>
>  #include <linux/pagemap.h>
>  
>  static int fuse_notify_poll(struct fuse_conn *fc, unsigned int size,
> @@ -192,7 +194,7 @@ static int fuse_notify_store(struct fuse_conn *fc, unsigned int size,
>  		if (!folio_test_uptodate(folio) && !err && folio_offset == 0 &&
>  		    (nr_bytes == folio_size(folio) || file_size == end)) {
>  			folio_zero_segment(folio, nr_bytes, folio_size(folio));
> -			folio_mark_uptodate(folio);
> +			iomap_folio_mark_uptodate(folio);

I wonder, if a fuse server stores to a range of dirty pagecache and
completely over-stores the dirty range, can that folio still get
scheduled for writeback?  I guess it's no big deal if that writeback
happens since the fuse server already knew about that content.

--D

>  		}
>  		folio_unlock(folio);
>  		folio_put(folio);
> -- 
> 2.52.0
>