lkml.org 
[lkml]   [2022]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-11-03 19:41    [W:0.057 / U:1.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site