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

"Darrick J. Wong" <[email protected]> Thu, 25 Jun 2026 11:57:50 -0700
Newsgroups dev.linux.lists.fuse-devel,org.kernel.vger.linux-fsdevel
Message-ID <20260625185750.GU6070@frogsfrogsfrogs>
On Wed, Jun 24, 2026 at 05:35:13PM -0700, Joanne Koong wrote:
> On Wed, Jun 24, 2026 at 3:18 PM Darrick J. Wong <[email protected]> wrote:
> >
> > > --- a/fs/fuse/notify.c
> > > +++ b/fs/fuse/notify.c
> > > @@ -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.
> >
> Yes I agree, I believe it still gets scheduled for writeback since it
> still has the dirty bit set.

Ok, seems fine to me then.  I hope there isn't a fuse server somewhere
depending on the "sorta immediate writeback of what I just stored via
this backchannel" behavior?

I mean, it would be crazy to implement an RNG based on jitter between
dirty->store->writeback, right??

Reviewed-by: "Darrick J. Wong" <[email protected]>

--D