Re: [PATCH 03/14] iov_iter: extract a iov_iter_extract_bvecs helper from bio code

[Christoph Hellwig <hch@lst.de>]

On Mon, Jan 26, 2026 at 05:36:12PM +0000, Matthew Wilcox wrote:
> > > Hmm, this just moves around existing code added in commit ed9832bc08db
> > > ("block: introduce folio awareness and add a bigger size from folio").
> > > 
> > > How do we get these network read buffers into either a user address
> > > space or a (non-bvec) iter passed to O_DIRECT reads/writes?
> > 
> > Splice from TCP socket to pipe, vmsplice from there into process address
> > space; DIO write() from there I think should do it.
> 
> Some other ways to get something that isn't a folio mapped into a user
> address space:
> 
>  - mmap() a vmalloc-allocated buffer.  We don't have a good story here
>    yet; we could declare every driver that does this to be buggy and
>    force them to allocate folios and vmap them.  Seems a bit
>    unreasonable and likely to end up with a lot of duplicate code with
>    bugs.  I've prototyped another approach, but it's not reeady to share
>    yet.
>  - mmap() the perf ring buffer.  We could decide to refuse to do DIO to
>    this buffer.

I'm confused.  Your example are all about something that would happen if
we actually split up what is currently struct page in some way.  But I
read Dave's mail as something is broken right now already.  Which of
those is the case?

> The eventual solution is that page_folio() will return NULL for pages
> which do not belong to folios.  That's independent of whether we decide
> to make user-mappable-vmalloc contain folios, or whether we have some
> other way to map/track pages-that-belong-to-vmalloc.

vmalloc is a tiny wrapper around alloc_page* + vmap/vm_map_area, and a
lot of code all over the kernel relies on that.  Trying to have a
separate "memory type" for vmalloc is going to break things left right
and center for not much obvious gain.  I'm not going to say you can't
do it, but I doubt that is actually ends up easy and particularly
useful.