linux-kernel - Re: [PATCH] mm/vmalloc: fix mischeck pfn valid in vmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <79247edd-761c-82e3-b8d2-acdbe31c8205@linux.intel.com>
Date: Mon, 17 Mar 2025 13:29:05 +0800
From: Bingbu Cao <bingbu.cao@...ux.intel.com>
To: Huan Yang <link@...o.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


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