linux-kernel - Re: [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to protect kernel pmd operations

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: <CAGsJ_4wPDxq=wK8zny-G+H9wV9ebouojfdwcoYNb6-_AJHMLdw@mail.gmail.com>
Date:   Sat, 18 Sep 2021 23:01:46 +1200
From:   Barry Song <21cnbao@...il.com>
To:     Muchun Song <songmuchun@...edance.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oscar Salvador <osalvador@...e.de>,
        Michal Hocko <mhocko@...e.com>,
        Barry Song <song.bao.hua@...ilicon.com>,
        David Hildenbrand <david@...hat.com>,
        Chen Huang <chenhuang5@...wei.com>,
        "Bodeddula, Balasubramaniam" <bodeddub@...zon.com>,
        Jonathan Corbet <corbet@....net>,
        Matthew Wilcox <willy@...radead.org>,
        Xiongchun duan <duanxiongchun@...edance.com>,
        fam.zheng@...edance.com, Muchun Song <smuchun@...il.com>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to
 protect kernel pmd operations

On Sat, Sep 18, 2021 at 10:51 PM Muchun Song <songmuchun@...edance.com> wrote:
>
> On Sat, Sep 18, 2021 at 1:07 PM Barry Song <21cnbao@...il.com> wrote:
> >
> > On Sat, Sep 18, 2021 at 12:09 AM Muchun Song <songmuchun@...edance.com> wrote:
> > >
> > > The init_mm.page_table_lock is used to protect kernel page tables, we
> > > can use it to serialize splitting vmemmap PMD mappings instead of mmap
> > > write lock, which can increase the concurrency of vmemmap_remap_free().
> > >
> >
> > Curious what is the actual benefit we get in user scenarios from this patch,
> > 1. we set bootargs to reserve hugetlb statically
> > 2. we "echo" some figures to sys or proc.
> >
> > In other words, Who is going to care about this concurrency?
>
> Actually, It increase the concurrency between allocations of
> HugeTLB pages. But it is not my first consideration. There are
> a lot of users of mmap read lock of init_mm. The mmap write
> lock is holding through vmemmap_remap_free(), I want to make
> it does not affect other users of mmap read lock.

generically makes sense. I guess it wouldn't be critical at all for hugetlb
allocation as practically we are not going to reserve and release hugtlb
often as they are not THP.

anyway, it is not making anything worse and always a win to move.

>
> I suppose a lot of developers are trying to avoid using mmap write
> lock. I am also one of them.
>
> > Can we have some details on this to put in the commit log?
>
> For sure. Those judgments above should be placed in the
> commit log.
>
> Thanks.

Thanks
barry