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

[Pranjal Shrivastava]

On Thu, Jun 25, 2026 at 11:56:08PM -0700, Christoph Hellwig wrote:
> [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.
> 

+1. I see that extract_bvecs also rely on user memory to have valid
folios even if we were to re-use parts of it (get_contig_folio_len) it
still relies on page_folio() as detailed in the other reply.

> 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.
> 

Do we have use-cases for a kernel user for direct I/O ? (Just curious to
know if there's something on the horizon).

Thanks,
Praan