On 4/6/25 11:39 PM, Christoph Hellwig wrote: > On Fri, Apr 04, 2025 at 09:59:40AM -0700, John Hubbard wrote: >>> gup_put_folio() seems to only rely on per-folio information (esp. >>> node_stat_mod_folio). >>> >>> So there should not be such a context requirement. >> >> That is correct. The essence of gup/pup is that it operates on >> struct pages, and doesn't have any "moral" connection to higher >> layers or additional process context. > > Hmm, indeed. I misremembered why the block based direct I/O code is > doing the process context offload, which is to call set_page_dirty to > redirty pages where the dirty bit was cleared during direct I/O. > > Which I think now that all block based file systems use FOLL_PIN > shouldn't be needed anymore, because no one can clear the dirty bit > while the folios are pinned? > No one should clear the dirty bit while the pages are pinned, agreed. This topic always worries me, because the original problem with dirty pages is still unfixed: setting pages dirty upon unpinning is both widely done (last time I checked), and yet broken, because it doesn't do a mkdirty() call to set up writeback buffers. The solution always seemed to point toward "get a file lease on that range, before pinning", but it's a contentious design area to say the least. thanks, -- John Hubbard
