linux-kernel - Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte

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]

Date:   Thu, 3 Nov 2022 11:38:25 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Peter Xu <peterx@...hat.com>
Cc:     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>,
        Nadav Amit <nadav.amit@...il.com>,
        Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte_offset() for its
 locking requirements

On 11/03/22 14:11, Peter Xu wrote:
> On Thu, Nov 03, 2022 at 08:42:01AM -0700, Mike Kravetz wrote:
> > On 10/30/22 17:29, Peter Xu wrote:
> > Not sure if it is worth calling out that we are safe if the process owning the
> > page table being walked is single threaded?  Although, a pmd can be 'unshared'
> > due to an operation in another process, the primary is when the pmd is cleared
> > which only happens when the unshare is initiated by a thread of the process
> > owning the page tables being walked.
> 
> Even if the process is single threaded, the pmd unshare can still trigger
> from other threads too, am I right?
> 
> Looking at huge_pmd_unshare() callers, the major ones that doesn't need
> current mm context are:
> 
>   - __unmap_hugepage_range() (e.g. hole punch from other process on file?)
>   - try_to_unmap_one()
>   - try_to_migrate_one()
> 
> So for example, even for a single thread process, if its pmd shared with
> another process, the other process can do (1) punch hole on pmd shared
> region, then (2) munmap() the pmd shared region, then it seems the single
> thread process can be still on risk of accessing freed pgtable.

Yes, you are correct.  I was not thinking about an unmap initiated by another
process doing something like hole punch or truncation.
-- 
Mike Kravetz