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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <339b0c1f-ce90-449f-a1fc-2656d5a1115c@vivo.com>
Date: Mon, 17 Mar 2025 10:12:20 +0800
From: Huan Yang <link@...o.com>
To: hch@....de
Cc: akpm@...ux-foundation.org, bingbu.cao@...ux.intel.com, link@...o.com,
 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 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ