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.
Thank you,
Huan Yang
