* Re: [PATCH 1/3] mm/hugetlb: Pre-allocate pgtable pages for uffd wr-protects
2023-01-04 22:52 ` [PATCH 1/3] mm/hugetlb: Pre-allocate pgtable pages for uffd wr-protects Peter Xu
@ 2023-01-05 1:50 ` James Houghton
2023-01-05 8:39 ` David Hildenbrand
2023-01-05 18:37 ` Mike Kravetz
2 siblings, 0 replies; 4+ messages in thread
From: James Houghton @ 2023-01-05 1:50 UTC (permalink / raw)
To: Peter Xu
Cc: linux-mm, linux-kernel, Mike Kravetz, Muchun Song, Nadav Amit,
Andrea Arcangeli, David Hildenbrand, Axel Rasmussen,
Andrew Morton, linux-stable
On Wed, Jan 4, 2023 at 10:52 PM Peter Xu <peterx@redhat.com> wrote:
>
> Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
> and hugetlb. Shmem has pre-allocation ready for markers, but hugetlb path
> was overlooked.
>
> Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
> find the huge ptep. It's possible that huge_pte_alloc() can fail with high
> memory pressure, in that case stop the loop immediately and fail silently.
> This is not the most ideal solution but it matches with what we do with
> shmem meanwhile it avoids the splat in dmesg.
>
> Cc: linux-stable <stable@vger.kernel.org> # 5.19+
> Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
> Reported-by: James Houghton <jthoughton@google.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> mm/hugetlb.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
Acked-by: James Houghton <jthoughton@google.com>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH 1/3] mm/hugetlb: Pre-allocate pgtable pages for uffd wr-protects
2023-01-04 22:52 ` [PATCH 1/3] mm/hugetlb: Pre-allocate pgtable pages for uffd wr-protects Peter Xu
2023-01-05 1:50 ` James Houghton
@ 2023-01-05 8:39 ` David Hildenbrand
2023-01-05 18:37 ` Mike Kravetz
2 siblings, 0 replies; 4+ messages in thread
From: David Hildenbrand @ 2023-01-05 8:39 UTC (permalink / raw)
To: Peter Xu, linux-mm, linux-kernel
Cc: Mike Kravetz, Muchun Song, Nadav Amit, Andrea Arcangeli,
James Houghton, Axel Rasmussen, Andrew Morton, linux-stable
On 04.01.23 23:52, Peter Xu wrote:
> Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
> and hugetlb. Shmem has pre-allocation ready for markers, but hugetlb path
> was overlooked.
>
> Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
> find the huge ptep. It's possible that huge_pte_alloc() can fail with high
> memory pressure, in that case stop the loop immediately and fail silently.
> This is not the most ideal solution but it matches with what we do with
> shmem meanwhile it avoids the splat in dmesg.
>
> Cc: linux-stable <stable@vger.kernel.org> # 5.19+
> Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
> Reported-by: James Houghton <jthoughton@google.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> mm/hugetlb.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index bf7a1f628357..017d9159cddf 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6649,8 +6649,17 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
> spinlock_t *ptl;
> ptep = hugetlb_walk(vma, address, psize);
if (!ptep && likely(!uffd_wp)) {
/* Nothing to protect. */
address |= last_addr_mask;
continue;
} else if (!ptep) {
...
}
Might look slightly more readable would minimize changes. This should
work, so
Acked-by: David Hildenbrand <david@redhat.com>
> if (!ptep) {
> - address |= last_addr_mask;
> - continue;
> + if (!uffd_wp) {
> + address |= last_addr_mask;
> + continue;
> + }
> + /*
> + * Userfaultfd wr-protect requires pgtable
> + * pre-allocations to install pte markers.
> + */
> + ptep = huge_pte_alloc(mm, vma, address, psize);
> + if (!ptep)
> + break;
> }
> ptl = huge_pte_lock(h, mm, ptep);
> if (huge_pmd_unshare(mm, vma, address, ptep)) {
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH 1/3] mm/hugetlb: Pre-allocate pgtable pages for uffd wr-protects
2023-01-04 22:52 ` [PATCH 1/3] mm/hugetlb: Pre-allocate pgtable pages for uffd wr-protects Peter Xu
2023-01-05 1:50 ` James Houghton
2023-01-05 8:39 ` David Hildenbrand
@ 2023-01-05 18:37 ` Mike Kravetz
2 siblings, 0 replies; 4+ messages in thread
From: Mike Kravetz @ 2023-01-05 18:37 UTC (permalink / raw)
To: Peter Xu
Cc: linux-mm, linux-kernel, Muchun Song, Nadav Amit, Andrea Arcangeli,
David Hildenbrand, James Houghton, Axel Rasmussen, Andrew Morton,
linux-stable
On 01/04/23 17:52, Peter Xu wrote:
> Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
> and hugetlb. Shmem has pre-allocation ready for markers, but hugetlb path
> was overlooked.
>
> Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
> find the huge ptep. It's possible that huge_pte_alloc() can fail with high
> memory pressure, in that case stop the loop immediately and fail silently.
> This is not the most ideal solution but it matches with what we do with
> shmem meanwhile it avoids the splat in dmesg.
>
> Cc: linux-stable <stable@vger.kernel.org> # 5.19+
> Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
> Reported-by: James Houghton <jthoughton@google.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> mm/hugetlb.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
Thanks Peter and James!
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
--
Mike Kravetz
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index bf7a1f628357..017d9159cddf 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6649,8 +6649,17 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
> spinlock_t *ptl;
> ptep = hugetlb_walk(vma, address, psize);
> if (!ptep) {
> - address |= last_addr_mask;
> - continue;
> + if (!uffd_wp) {
> + address |= last_addr_mask;
> + continue;
> + }
> + /*
> + * Userfaultfd wr-protect requires pgtable
> + * pre-allocations to install pte markers.
> + */
> + ptep = huge_pte_alloc(mm, vma, address, psize);
> + if (!ptep)
> + break;
> }
> ptl = huge_pte_lock(h, mm, ptep);
> if (huge_pmd_unshare(mm, vma, address, ptep)) {
> --
> 2.37.3
>
^ permalink raw reply [flat|nested] 4+ messages in thread