lkml.org 
[lkml]   [2022]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH RFC 04/10] mm/hugetlb: Make userfaultfd_huge_must_wait() RCU-safe
    On Sun, Oct 30, 2022 at 2:29 PM Peter Xu <peterx@redhat.com> wrote:
    >
    > RCU makes sure the pte_t* won't go away from under us. Please refer to the
    > comment above huge_pte_offset() for more information.
    >
    > Signed-off-by: Peter Xu <peterx@redhat.com>
    > ---
    > fs/userfaultfd.c | 4 ++++
    > 1 file changed, 4 insertions(+)
    >
    > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
    > index 07c81ab3fd4d..4e813e68e4f8 100644
    > --- a/fs/userfaultfd.c
    > +++ b/fs/userfaultfd.c
    > @@ -243,6 +243,9 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx,
    >
    > mmap_assert_locked(mm);
    >
    > + /* For huge_pte_offset() */
    > + rcu_read_lock();

    userfaultfd_huge_must_wait is called after we set the task's state to
    blocking. Is it always safe to call rcu_read_lock (and
    rcu_read_unlock) in this case? (With my basic understanding of RCU,
    this seems like it should be safe, but I'm not sure.)

    - James


    > +
    > ptep = huge_pte_offset(mm, address, vma_mmu_pagesize(vma));
    >
    > if (!ptep)
    > @@ -261,6 +264,7 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx,
    > if (!huge_pte_write(pte) && (reason & VM_UFFD_WP))
    > ret = true;
    > out:
    > + rcu_read_unlock();
    > return ret;
    > }
    > #else
    > --
    > 2.37.3
    >

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