On 3/17/25 10:12 AM, Huan Yang wrote: > HI Christoph, > > Thanks for your reply, and I'm sorry for my late reply. Your response > didn't appear in my email client; I only saw it on the website.:( > >>> On Wed, Mar 12, 2025 at 02:15:12PM +0800, Huan Yang wrote: >>> When invoke vmap_pfns, it call vmap_pfn_apply to set pfn into pte. >> It check pfn is valid, if true then warn and return. >> >> This is > a mischeck, actually we need set a valid pfn into pte, not an >> invalid pfn. > >> As just discussed this is wrong. vmap_pfn is for mapping non-page > Thank you for your explanation. I now understand that the design of vmap_pfn > is indeed intentional. It's design to do this. >> PFNs and the check is what enforces that. What is the point of having >> that detailed discussion if you just send the broken patch anyway with >> a commit log not even acknowledging the facts? > Sorry for that. > > We now have a new use case where, in udmabuf, memory is passed via memfd and can > be either shmem or hugetlb. > When the memory is hugetlb and HVO is enabled, the tail page's struct is no longer > reliable because it has been freed. Can't use vmap. > Therefore, when making modifications, I recorded the pfn of the folio base pfn + offset and called vmap_pfns. > And, these pfns are valid. So rejected by vmap_pfns. > > Can we just remove pfn_valid check in vmap_pfns, so make it suit for both of they? > If you agree, I wanna send a new patch. Huan, Why not update udmabuf to make it work with both vmap_pfns() and vmap()? As only the udmabuf knows it is actually working on? I don't think it's a good idea to hack the common API, the WARN_ON() is really a mandatory check, and current case is a good example. > > Thank you, > Huan Yang > -- Best regards, Bingbu Cao
