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
| ||
|
Message-ID: <CAMZfGtUcGGuq4ZoS44aMAYfYZQk-S-cJap3LZKLS-2fgi_s3Rw@mail.gmail.com> Date: Thu, 3 Mar 2022 10:28:17 +0800 From: Muchun Song <songmuchun@...edance.com> To: Mike Kravetz <mike.kravetz@...cle.com> Cc: Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>, Luis Chamberlain <mcgrof@...nel.org>, Kees Cook <keescook@...omium.org>, Iurii Zaikin <yzaikin@...gle.com>, Linux Doc Mailing List <linux-doc@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Linux Memory Management List <linux-mm@...ck.org>, Xiongchun duan <duanxiongchun@...edance.com>, Muchun Song <smuchun@...il.com> Subject: Re: [PATCH v2 1/3] mm: hugetlb: disable freeing vmemmap pages when struct page crosses page boundaries On Thu, Mar 3, 2022 at 8:25 AM Mike Kravetz <mike.kravetz@...cle.com> wrote: > > On 3/2/22 00:37, Muchun Song wrote: > > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > > of "struct page" is not power of two, we cannot optimize vmemmap pages > > of HugeTLB pages. We should disable this feature in this case. > > I'll let you reply to the question from Luis, but IIUC there is no issue > today as "struct page" is certainly a power of two. This is more future > looking. Correct? Partly right. The size of "struct page" is not the power of two if !CONFIG_MEMCG && CONFIG_SLAB on x86_64. But it is not a conventional configuration nowadays. So it is not a critical problem. I am not sure if a Fixes tag is necessary. > > > Signed-off-by: Muchun Song <songmuchun@...edance.com> > > --- > > mm/hugetlb_vmemmap.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > > index b3118dba0518..836d1117f08b 100644 > > --- a/mm/hugetlb_vmemmap.c > > +++ b/mm/hugetlb_vmemmap.c > > @@ -121,6 +121,17 @@ void __init hugetlb_vmemmap_init(struct hstate *h) > > if (!hugetlb_free_vmemmap_enabled()) > > return; > > > > + if (IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON) && > > + !is_power_of_2(sizeof(struct page))) { > > + /* > > + * The hugetlb_free_vmemmap_enabled_key can be enabled when > > + * CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON. It should > > + * be disabled if "struct page" crosses page boundaries. > > + */ > > + static_branch_disable(&hugetlb_free_vmemmap_enabled_key); > > Should we possibly print a warning here as in the routine early_hugetlb_free_vmemmap_param? This is called once per hstate, so > perhaps pr_warn_once. Good point. Will do. Thanks.
Powered by blists - more mailing lists