[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231006175719.GA3861@monkey>
Date: Fri, 6 Oct 2023 10:57:19 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: riel@...riel.com
Cc: linux-kernel@...r.kernel.org, kernel-team@...a.com,
linux-mm@...ck.org, akpm@...ux-foundation.org,
muchun.song@...ux.dev, leit@...a.com, willy@...radead.org,
stable@...nel.org
Subject: Re: [PATCH 3/4] hugetlbfs: close race between MADV_DONTNEED and page
fault
On 10/05/23 23:59, riel@...riel.com wrote:
> From: Rik van Riel <riel@...riel.com>
>
> Malloc libraries, like jemalloc and tcalloc, take decisions on when
> to call madvise independently from the code in the main application.
>
> This sometimes results in the application page faulting on an address,
> right after the malloc library has shot down the backing memory with
> MADV_DONTNEED.
>
> Usually this is harmless, because we always have some 4kB pages
> sitting around to satisfy a page fault. However, with hugetlbfs
> systems often allocate only the exact number of huge pages that
> the application wants.
>
> Due to TLB batching, hugetlbfs MADV_DONTNEED will free pages outside of
> any lock taken on the page fault path, which can open up the following
> race condition:
>
> CPU 1 CPU 2
>
> MADV_DONTNEED
> unmap page
> shoot down TLB entry
> page fault
> fail to allocate a huge page
> killed with SIGBUS
> free page
>
> Fix that race by pulling the locking from __unmap_hugepage_final_range
> into helper functions called from zap_page_range_single. This ensures
> page faults stay locked out of the MADV_DONTNEED VMA until the
> huge pages have actually been freed.
>
> Signed-off-by: Rik van Riel <riel@...riel.com>
> Cc: stable@...nel.org
> Fixes: 04ada095dcfc ("hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing")
> ---
> include/linux/hugetlb.h | 35 +++++++++++++++++++++++++++++++++--
> mm/hugetlb.c | 34 ++++++++++++++++++++++------------
> mm/memory.c | 13 ++++++++-----
> 3 files changed, 63 insertions(+), 19 deletions(-)
Thanks for all the revisions,
Reviewed-by: Mike Kravetz <mike.kravetz@...cle.com>
--
Mike Kravetz
Powered by blists - more mailing lists