[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb36378e-a3ab-4ac4-a71f-ccc95f96361e@vivo.com>
Date: Mon, 17 Mar 2025 14:26:31 +0800
From: Huan Yang <link@...o.com>
To: Bingbu Cao <bingbu.cao@...ux.intel.com>, hch@....de
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, lorenzo.stoakes@...cle.com, opensource.kernel@...o.com,
rppt@...nel.org, ryan.roberts@....com, urezki@...il.com, ziy@...dia.com
Subject: Re: [PATCH] mm/vmalloc: fix mischeck pfn valid in vmap_pfns
Hi Bingbu
在 2025/3/17 13:29, Bingbu Cao 写道:
> 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?
You mean, If udmabuf invoke vmap if it's normal page-based folio range,
else invoke vmap_pfns
if it's in HVO based?
udmabuf can contained a rane in folio and offset, what if it contains
folio's head(with page struct) and
remain tail(without page struct, freed by HVO).
I think there are no suitable way to map it into vmalloc area.:)
Or else, just block hugetlb's folio mapped into vmalloc area? Which I
don't think it's a good way.
>
> I don't think it's a good idea to hack the common API, the WARN_ON()
You mean common, but I think vmalloc can provide a more common API that
not care if page it's
exist, if provide pfn, just map? :)
Or else, document it that vmap_pfn just do not welcome page based pfn
map?(Just IMO)
Thanks,
Huan Yang
> is really a mandatory check, and current case is a good example.
>
>> Thank you,
>> Huan Yang
>>
Powered by blists - more mailing lists