RE: [PATCH] lib/scatterlist: fix sg_page_count and sg_dma_page_count

[Kasireddy, Vivek]

Hi Jason,

> Subject: Re: [PATCH] lib/scatterlist: fix sg_page_count and
> sg_dma_page_count
> 
> On Tue, Mar 10, 2026 at 05:49:23AM +0000, Kasireddy, Vivek wrote:
> > There are a couple of reasons why we got rid of the pages array:
> > - Back then, there was some confusion about whether a struct page
> would
> >   exist or not for tail pages when HVO is enabled. Regardless, there was
> also
> >   a concern about exposing tail pages outside hugetlb code.
> 
> The existing code relies on struct page for the vmap:
Right, but IMO, this (using struct page in vmap) is a temporary fix until an
appropriate folio/pfn based API is available. We had used vmap_pfn()
earlier but realized that it was not intended to be used for mapping
struct page/folio backed memory.

> 
>         for (pg = 0; pg < ubuf->pagecount; pg++)
>                 pages[pg] = folio_page(ubuf->folios[pg],
>                                        ubuf->offsets[pg] >> PAGE_SHIFT);
> 
> Tail pages always exist, they are required by many interfaces.
Right, hugetlb maintainer (Muchun) confirmed that the tail pages exist
in "read-only" mode when HVO is enabled.

> 
> > - And, we also wanted to prepare for a future where struct page would
> not
> >   exist anymore, so, it made sense to just use folios only.
> 
> If you can 100% stick with whole folios then great, but we don't have
> the APIs for that cases udmabuf needs right now. Most likely we'd
> expect to use phys_addr_t for scatterlist and direct full folio for
> vmap. Neither is helped by the datastructure in udmabuf.
So, given the current situation, what is the right thing to do?
Should we take your patch that brings back the pages array and treat it as
a temporary fix until equivalent folio based APIs are available?

Thanks,
Vivek

> 
> Jason