All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: riel@surriel.com
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	muchun.song@linux.dev, leit@meta.com, willy@infradead.org
Subject: Re: [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs
Date: Mon, 25 Sep 2023 15:25:01 -0700	[thread overview]
Message-ID: <20230925222501.GA55705@monkey> (raw)
In-Reply-To: <20230925203030.703439-2-riel@surriel.com>

On 09/25/23 16:28, riel@surriel.com wrote:
> From: Rik van Riel <riel@surriel.com>
> 
> Extend the locking scheme used to protect shared hugetlb mappings
> from truncate vs page fault races, in order to protect private
> hugetlb mappings (with resv_map) against MADV_DONTNEED.

The only time an anon hugetlb mapping would not have a resv_map would
be in the case where MAP_NORESERVE was specified.  In this case the user
should be prepared for allocation failures.  I am good with this approach
not adding locking for the MAP_NORESERVE case.

> Add a read-write semaphore to the resv_map data structure, and
> use that from the hugetlb_vma_(un)lock_* functions, in preparation
> for closing the race between MADV_DONTNEED and page faults.
> 
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
>  include/linux/hugetlb.h |  6 ++++++
>  mm/hugetlb.c            | 41 +++++++++++++++++++++++++++++++++++++----
>  2 files changed, 43 insertions(+), 4 deletions(-)

Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>

-- 
Mike Kravetz

  reply	other threads:[~2023-09-25 22:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25 20:28 [PATCH v3 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-09-25 20:28 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel
2023-09-25 22:25   ` Mike Kravetz [this message]
2023-09-25 20:28 ` [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-09-25 22:25   ` Mike Kravetz
2023-09-26  0:46     ` Rik van Riel
2023-09-25 20:28 ` [PATCH 3/3] hugetlbfs: replace hugetlb_vma_lock with invalidate_lock riel
  -- strict thread matches above, loose matches on Subject: below --
2023-10-04  3:25 [PATCH v6 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-10-04  3:25 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel
2023-10-01  0:55 [PATCH v5 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-10-01  0:55 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel
2023-09-26  3:10 [PATCH v4 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-09-26  3:10 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel
2023-09-30  2:28   ` Mike Kravetz
2023-09-30 19:48     ` Rik van Riel
2023-09-22 19:02 [PATCH v2 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-09-22 19:02 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230925222501.GA55705@monkey \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=kernel-team@meta.com \
    --cc=leit@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=riel@surriel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.