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: <CADrL8HWJvxGej8arUtCch_=OcFy_vzo11rD0yRK8ey_Oe2BHXQ@mail.gmail.com>
Date:   Thu, 12 Jan 2023 08:38:02 -0500
From:   James Houghton <jthoughton@...gle.com>
To:     Peter Xu <peterx@...hat.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <songmuchun@...edance.com>,
        David Hildenbrand <david@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Mina Almasry <almasrymina@...gle.com>,
        "Zach O'Keefe" <zokeefe@...gle.com>,
        Manish Mishra <manish.mishra@...anix.com>,
        Naoya Horiguchi <naoya.horiguchi@....com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        Yang Shi <shy828301@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/46] hugetlb: add hugetlb_hgm_walk and hugetlb_walk_step

On Wed, Jan 11, 2023 at 4:51 PM Peter Xu <peterx@...hat.com> wrote:
>
> On Thu, Jan 05, 2023 at 10:18:11AM +0000, James Houghton wrote:
>
> [...]
>
> > +static int hugetlb_hgm_walk_uninit(struct hugetlb_pte *hpte,
>
> Nitpick on the name: the "uninit" can be misread into pairing with some
> other "init()" calls..
>
> How about just call it hugetlb_hgm_walk (since it's the higher level API
> comparing to the existing one)?  Then the existing hugetlb_hgm_walk can be
> called hugetlb_hgm_do_walk/__hugetlb_hgm_walk since it's one level down.
>
> > +                                pte_t *ptep,
> > +                                struct vm_area_struct *vma,
> > +                                unsigned long addr,
> > +                                unsigned long target_sz,
> > +                                bool alloc)
> > +{
> > +     struct hstate *h = hstate_vma(vma);
> > +
> > +     hugetlb_pte_populate(vma->vm_mm, hpte, ptep, huge_page_shift(h),
> > +                          hpage_size_to_level(huge_page_size(h)));
>
> Another nitpick on name: I remembered we used to reach a consensus of using
> hugetlb_pte_init before?  Can we still avoid the word "populate" (if "init"
> is not suitable since it can be updated during stepping, how about "setup")?

Right, we did talk about this, sorry. Ok I'll go ahead with this name change.
- hugetlb_hgm_walk => __hugetlb_hgm_walk
- hugetlb_hgm_walk_uninit => hugetlb_hgm_walk
- [__,]hugetlb_pte_populate => [__,]hugetlb_pte_init

>
> [...]
>
> > +int hugetlb_walk_step(struct mm_struct *mm, struct hugetlb_pte *hpte,
> > +                   unsigned long addr, unsigned long sz)
> > +{
> > +     pte_t *ptep;
> > +     spinlock_t *ptl;
> > +
> > +     switch (hpte->level) {
> > +     case HUGETLB_LEVEL_PUD:
> > +             ptep = (pte_t *)hugetlb_alloc_pmd(mm, hpte, addr);
> > +             if (IS_ERR(ptep))
> > +                     return PTR_ERR(ptep);
> > +             hugetlb_pte_populate(mm, hpte, ptep, PMD_SHIFT,
> > +                                  HUGETLB_LEVEL_PMD);
> > +             break;
> > +     case HUGETLB_LEVEL_PMD:
> > +             ptep = hugetlb_alloc_pte(mm, hpte, addr);
> > +             if (IS_ERR(ptep))
> > +                     return PTR_ERR(ptep);
> > +             ptl = pte_lockptr(mm, (pmd_t *)hpte->ptep);
> > +             __hugetlb_pte_populate(hpte, ptep, PAGE_SHIFT,
> > +                                    HUGETLB_LEVEL_PTE, ptl);
> > +             hpte->ptl = ptl;
>
> This line seems to be superfluous (even if benign).

Nice catch! It shouldn't be there; I accidentally left it in when I
changed how `ptl` was handled.

Thanks Peter!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ