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