linux-kernel - Re: [PATCH v6 09/16] mm/hugetlb: Defer freeing of HugeTLB pages

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: <20201124115109.GW27488@dhcp22.suse.cz>
Date:   Tue, 24 Nov 2020 12:51:09 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Muchun Song <songmuchun@...edance.com>
Cc:     corbet@....net, mike.kravetz@...cle.com, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
        dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
        viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
        paulmck@...nel.org, mchehab+huawei@...nel.org,
        pawan.kumar.gupta@...ux.intel.com, rdunlap@...radead.org,
        oneukum@...e.com, anshuman.khandual@....com, jroedel@...e.de,
        almasrymina@...gle.com, rientjes@...gle.com, willy@...radead.org,
        osalvador@...e.de, song.bao.hua@...ilicon.com,
        duanxiongchun@...edance.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v6 09/16] mm/hugetlb: Defer freeing of HugeTLB pages

On Tue 24-11-20 17:52:52, Muchun Song wrote:
> In the subsequent patch, we will allocate the vmemmap pages when free
> HugeTLB pages. But update_and_free_page() is called from a non-task
> context(and hold hugetlb_lock), so we can defer the actual freeing in
> a workqueue to prevent use GFP_ATOMIC to allocate the vmemmap pages.

This has been brought up earlier without any satisfying answer. Do we
really have bother with the freeing from the pool and reconstructing the
vmemmap page tables? Do existing usecases really require such a dynamic
behavior? In other words, wouldn't it be much simpler to allow to use
hugetlb pages with sparse vmemmaps only for the boot time reservations
and never allow them to be freed back to the allocator. This is pretty
restrictive, no question about that, but it would drop quite some code
AFAICS and the resulting series would be much easier to review really
carefully. Additional enhancements can be done on top with specifics
about usecases which require more flexibility.

> Signed-off-by: Muchun Song <songmuchun@...edance.com>
> ---
>  mm/hugetlb.c         | 96 ++++++++++++++++++++++++++++++++++++++++++++++------
>  mm/hugetlb_vmemmap.c |  5 ---
>  mm/hugetlb_vmemmap.h | 10 ++++++
>  3 files changed, 95 insertions(+), 16 deletions(-)
-- 
Michal Hocko
SUSE Labs