Re: [PATCH v2 6/7] nfs: Optimize direct I/O to use folios for requests

[Christoph Hellwig <hch@infradead.org>]

[sorry, dropped the ball a bit on this due to overload]

On Thu, Jun 18, 2026 at 07:20:06PM +0100, Matthew Wilcox wrote:
> On Thu, Jun 18, 2026 at 07:10:45AM -0700, Christoph Hellwig wrote:
> > On Tue, Jun 16, 2026 at 05:23:48PM +0000, Pranjal Shrivastava wrote:
> > > AFAIU, the MM subsystem explicitly ensures that every valid struct page
> > > is part of a folio.
> > 
> > It is definitively not what the vision for the folio is, although if
> > I'm not mistaken it actually is still true right now.
> 
> It's not true, eg, for slab.  While there's still a struct page there
> for slab, there's no refcount and flags like PG_locked have different
> meanings.  You'll get into a lot of trouble trying to treat slabs as
> folios (and that will include assertions tripping).

True.  But also not relevant for direct I/O user pinning.  If we stopped
having valid folios for anything mapped into userspace,
iov_iter_extract_bvecs would run into problems, and we had the discussion
before that at least right now it would be hard to fix.

Also if iov_iter_extract_bvecs was used on kvec or bvec iters we could
run into the slab problem.  The block usage currently makes sure bvec
iters are not handed to iov_iter_extract_bvecs, but there is no such
thing for kvec vectors, although no one is using them for direct I/O
right now.  Not that I'd want to rely on that in the long run.