Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte_offset() for its locking requirements

[Mike Kravetz <mike.kravetz@oracle.com>]

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