Re: [PATCH RFC 04/10] mm/hugetlb: Make userfaultfd_huge_must_wait() RCU-safe

[James Houghton]

On Sun, Oct 30, 2022 at 2:29 PM Peter Xu <peterx@xxxxxxxxxx> 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@xxxxxxxxxx>
> ---
>  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
>