On Sat, Jun 01, 2024 at 06:51:45PM +0100, Matthew Wilcox wrote: > On Fri, May 31, 2024 at 10:28:50AM +0900, Damien Le Moal wrote: > > >> This will stop working at some point. It'll return NULL once we get > > >> to the memdesc future (because the memdesc will be a slab, not a folio). > > > > > > Hmmm, xfs_buf.c plays a similar trick here for sub-page buffers. I'm > > > assuming that will get ported to ... whatever the memdesc future holds? > > I don't think it does, exactly? Are you referring to kmem_to_page()? > That will continue to work. You're not trying to get a folio from a > slab allocation; that will start to fail. The point is that we doing block I/O on a slab allocation is heavily used, and zonefs does this. If you dislike going through the folio we can just keep using pages in zonefs for now. Eventually I'll get around lifting the logic to greedily build a bio from arbitrary kernel virtual addresses from various places in XFS into common code and we can convert to that. > I think you should use read_mapping_folio() for now instead of > complicating zonefs. Once there's a grand new buffer cache, switch to > that, but I don't think you're introducing a significant vulnerability > by using the block device's page cache. Please don't add pointless uses of the bdev page cache for users that don't need caching. This just creates more headaches later on to untangle it again.
