linux-kernel - Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

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: <72e772bc-7103-62da-d834-059eb5a3ce5b@oracle.com>
Date:   Thu, 11 Feb 2021 10:05:19 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Muchun Song <songmuchun@...edance.com>, corbet@....net,
        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, mhocko@...e.com,
        song.bao.hua@...ilicon.com, david@...hat.com,
        naoya.horiguchi@....com, joao.m.martins@...cle.com
Cc:     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 v15 4/8] mm: hugetlb: alloc the vmemmap pages associated
 with each HugeTLB page

On 2/8/21 12:50 AM, Muchun Song wrote:
> When we free a HugeTLB page to the buddy allocator, we should allocate the
> vmemmap pages associated with it. But we may cannot allocate vmemmap pages
> when the system is under memory pressure, in this case, we just refuse to
> free the HugeTLB page instead of looping forever trying to allocate the
> pages.
> 
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
> ---
>  include/linux/mm.h   |  2 ++
>  mm/hugetlb.c         | 19 ++++++++++++-
>  mm/hugetlb_vmemmap.c | 30 +++++++++++++++++++++
>  mm/hugetlb_vmemmap.h |  6 +++++
>  mm/sparse-vmemmap.c  | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  5 files changed, 130 insertions(+), 2 deletions(-)

Muchun has done a great job simplifying this patch series and addressing
issues as they are brought up.  This patch addresses the issue which seems
to be the biggest stumbling block to this series.  The need to allocate
vmemmap pages to dissolve a hugetlb page to the buddy allocator.  The way
it is addressed in this patch is to simply fail to dissolve the hugetlb
page if the vmmemmap pages can not be allocated.  IMO, this is an 'acceptable'
strategy.  If we find ourselves in this situation then we are likely to be
hitting other corner cases in the system.  I wish there was a perfect way
to address this issue, but we have been unable to come up with one.

There was a decent discussion about this is a previous version of the
series starting here:
https://lore.kernel.org/linux-mm/20210126092942.GA10602@linux/
In this thread various other options were suggested and discussed.

I would like to come to some agreement on an acceptable way to handle this
specific issue.  IMO, it makes little sense to continue refining other
parts of this series if we can not figure out how to move forward on this
issue.

It would be great if David H, David R and Michal could share their opinions
on this.  No need to review details the code yet (unless you want), but
let's start a discussion on how to move past this issue if we can.
-- 
Mike Kravetz