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: <Y2LYSYLj94ajCaOI@x1n>
Date:   Wed, 2 Nov 2022 16:51:21 -0400
From:   Peter Xu <peterx@...hat.com>
To:     Nadav Amit <nadav.amit@...il.com>
Cc:     kernel list <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Houghton <jthoughton@...gle.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        David Hildenbrand <david@...hat.com>,
        Muchun Song <songmuchun@...edance.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte_offset() for its
 locking requirements

On Mon, Oct 31, 2022 at 10:46:52PM -0700, Nadav Amit wrote:
> On Oct 30, 2022, at 2:29 PM, Peter Xu <peterx@...hat.com> wrote:
> 
> > huge_pte_offset() is potentially a pgtable walker, looking up pte_t* for a
> > hugetlb address.
> > 
> > Normally, it's always safe to walk the pgtable as long as we're with the
> > mmap lock held for either read or write, because that guarantees the
> > pgtable pages will always be valid during the process.
> > 
> > But it's not true for hugetlbfs: hugetlbfs has the pmd sharing feature, it
> > means that even with mmap lock held, the PUD pgtable page can still go away
> > from under us if pmd unsharing is possible during the walk.
> > 
> > It's not always the case, e.g.:
> > 
> >  (1) If the mapping is private we're not prone to pmd sharing or
> >      unsharing, so it's okay.
> > 
> >  (2) If we're with the hugetlb vma lock held for either read/write, it's
> >      okay too because pmd unshare cannot happen at all.
> > 
> > Document all these explicitly for huge_pte_offset(), because it's really
> > not that obvious.  This also tells all the callers on what it needs to
> > guarantee huge_pte_offset() thread-safety.
> > 
> > Signed-off-by: Peter Xu <peterx@...hat.com>
> > ---
> > arch/arm64/mm/hugetlbpage.c | 32 ++++++++++++++++++++++++++++++++
> 
> Please excuse my ignorant question - is there something specific for arm64
> code here? Other archs seem to have similar code, no?

Oops, sorry, I meant to add this to the version in mm/hugetlb.c.  Or maybe
to linux/hugetlb.h would make more sense.

I should probably also mention that for any arch that does not support pmd
sharing at all (afaik, any arch outside arm, x86 and riscv), the shared
mapping locking rule should be the same as private.

-- 
Peter Xu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ