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] [day] [month] [year] [list]
Date: Wed, 5 Jun 2024 10:56:54 +0200
From: David Hildenbrand <david@...hat.com>
To: xu.xin16@....com.cn, willy@...radead.org, ziy@...dia.com,
 akpm@...ux-foundation.org
Cc: ran.xiaokai@....com.cn, yang.yang29@....com.cn, mhocko@...nel.org,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH linux-next] mm: huge_memory: remove
 is_transparent_hugepage()

On 05.06.24 10:37, xu.xin16@....com.cn wrote:
> From: Ran Xiaokai <ran.xiaokai@....com.cn>
> 
> is_transparent_hugepage() was first introduced to ensure the page is
> 2M THP page. After commit de53c05f2ae3 ("mm: add large_rmappable
> page flag") and commit fc4d182316bd ("mm: huge_memory: enable debugfs
> to split huge pages to any order"), any large folio of mTHP suitable order
> can be split, not only 2M THP page.

Yes.

> so the check in split_huge_pages_pid() is not needed here, instead
> a folio_test_large() check is sufficient. To ensure a 2M THP folio,
> we should use "folio_order(folio) == HPAGE_PMD_ORDER" for now.

What about some kernel-allocated large folio that got mapped using 
vm_insert_pages() and friends? Are we sure these pages (that are not 
large_rmappable and not splittable) are properly handled?

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ