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: <fe65a409-b989-5e05-952e-6fcf6aa2ab55@oracle.com>
Date:   Mon, 14 Jun 2021 20:52:37 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Muchun Song <songmuchun@...edance.com>
Cc:     osalvador@...e.de, mhocko@...e.com, song.bao.hua@...ilicon.com,
        david@...hat.com, chenhuang5@...wei.com, bodeddub@...zon.com,
        corbet@....net, duanxiongchun@...edance.com,
        fam.zheng@...edance.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v2 0/3] Split huge PMD mapping of vmemmap pages

On 6/14/21 6:12 PM, Andrew Morton wrote:
> On Sat, 12 Jun 2021 17:45:52 +0800 Muchun Song <songmuchun@...edance.com> wrote:
> 
>> In order to reduce the difficulty of code review in series[1]. We disable
>> huge PMD mapping of vmemmap pages when that feature is enabled. In this
>> series, we do not disable huge PMD mapping of vmemmap pages anymore. We
>> will split huge PMD mapping when needed. When HugeTLB pages are freed from
>> the pool we do not attempt coalasce and move back to a PMD mapping because
>> it is much more complex.
>>
>> [1] https://lore.kernel.org/linux-doc/20210510030027.56044-1-songmuchun@bytedance.com/
> 
> [1] had a nice [0/n] description but the v2 series lost that.  I could
> copy/paste the v1 changelogging but I am unsure that it has been
> maintained appropriately for the v2 series.
> 
> I think I'll pass on this v2 pending additional review input.  Please reinstate
> the [0/n] overview if/when resending?

There may be some confusion.

This series is a follow on optimization for the functionality provided by
[1].  Early in the development of [1], it was decided to drop some code
for ease of review.  Specifically, splitting vmemmap PMD mappings to PTE
mappings as required when hugetlb pages were allocated.  The
'simplification' in [1] is that if the feature is enabled then vmemmap
will only be mapped with PTEs.

This series provides the ability to split PMD mappings 'on demand' as
hugetlb pages are allocated.  As mentioned, it really is a follow on and
optimization to functionality provided in [1].  As such, I am not sure
that repeating the [0/n] description from 1 is necessary here.

In any case, this should be clearly stated in the [0/n] description of
this series.

BTW- I did get through the series today, and did not discover any
issues.  However, I want to sleep on it before signing off.
-- 
Mike Kravetz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ