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

[Christoph Hellwig <hch@lst.de>]

On Tue, Jan 27, 2026 at 05:44:01AM +0000, Matthew Wilcox wrote:
> > 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?
> 
> What's broken right now is that the network buffers are now using frozen
> pages, so they have a zero refcount (Dave, do I remember the current
> state of play correctly?)

Nothing using this function right now ever deals with the page refcounts,
so that should not be an issue.

> > 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.
> 
> Most of the code in the kernel doesn't drill down from vmalloc to page.
> I don't think it's going to be all that painful, but I also don't think
> I'll need to address vmalloc in the first half of this year.  Just trying
> to fill you in on the current plans.

Maybe not most of the kernel, but vmalloc_to_page and is_vmalloc_addr
are used in quite a lot of places, and usually need to handle both
actual vmalloc allocations, and page/folio allocations mapped into
vmalloc space.