public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Suren Baghdasaryan <surenb@google.com>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Jann Horn <jannh@google.com>,
	David Hildenbrand <david@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org,
	John Hubbard <jhubbard@nvidia.com>,
	Juan Yescas <jyescas@google.com>,
	Kalesh Singh <kaleshsingh@google.com>
Subject: Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings
Date: Tue, 18 Feb 2025 13:12:05 +0100	[thread overview]
Message-ID: <fbfae348-909b-48fa-9083-67696b02f15e@suse.cz> (raw)
In-Reply-To: <cover.1739469950.git.lorenzo.stoakes@oracle.com>

On 2/13/25 19:16, Lorenzo Stoakes wrote:
> The guard regions feature was initially implemented to support anonymous
> mappings only, excluding shmem.
> 
> This was done such as to introduce the feature carefully and incrementally
> and to be conservative when considering the various caveats and corner
> cases that are applicable to file-backed mappings but not to anonymous
> ones.
> 
> Now this feature has landed in 6.13, it is time to revisit this and to
> extend this functionality to file-backed and shmem mappings.
> 
> In order to make this maximally useful, and since one may map file-backed
> mappings read-only (for instance ELF images), we also remove the
> restriction on read-only mappings and permit the establishment of guard
> regions in any non-hugetlb, non-mlock()'d mapping.

Do you plan to address mlock later too? I guess somebody might find use for
those. Is there some fundamental issue or just that we need to define some
good semantics for corner cases? (i.e. if pages are already populated in the
mlocked area, discarding them by replacing with guard pte's goes against
that, so do we allow it or not?).

Otherwise nice discussion of all the potential issues here!



  parent reply	other threads:[~2025-02-18 12:12 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13 18:16 [PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings Lorenzo Stoakes
2025-02-13 18:17 ` [PATCH 1/4] mm: allow guard regions in file-backed and read-only mappings Lorenzo Stoakes
2025-02-18 14:15   ` Vlastimil Babka
2025-02-18 16:01   ` David Hildenbrand
2025-02-18 16:12     ` Lorenzo Stoakes
2025-02-18 16:17       ` David Hildenbrand
2025-02-18 16:21         ` Lorenzo Stoakes
2025-02-18 16:27           ` David Hildenbrand
2025-02-18 16:49             ` Lorenzo Stoakes
2025-02-18 17:00               ` David Hildenbrand
2025-02-18 17:04                 ` Lorenzo Stoakes
2025-02-24 14:02   ` Lorenzo Stoakes
2025-02-13 18:17 ` [PATCH 2/4] selftests/mm: rename guard-pages to guard-regions Lorenzo Stoakes
2025-02-18 14:15   ` Vlastimil Babka
2025-03-02  8:35   ` Lorenzo Stoakes
2025-02-13 18:17 ` [PATCH 3/4] tools/selftests: expand all guard region tests to file-backed Lorenzo Stoakes
2025-02-18 14:17   ` Vlastimil Babka
2025-04-22 10:37   ` Ryan Roberts
2025-04-22 10:47     ` Lorenzo Stoakes
2025-04-22 11:03       ` Ryan Roberts
2025-04-22 11:07         ` Lorenzo Stoakes
2025-04-22 11:11           ` Ryan Roberts
2025-02-13 18:17 ` [PATCH 4/4] tools/selftests: add file/shmem-backed mapping guard region tests Lorenzo Stoakes
2025-02-18 14:18   ` Vlastimil Babka
2025-02-18 12:12 ` Vlastimil Babka [this message]
2025-02-18 13:05   ` [PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings Lorenzo Stoakes
2025-02-18 14:35     ` David Hildenbrand
2025-02-18 14:53       ` Lorenzo Stoakes
2025-02-18 15:20         ` David Hildenbrand
2025-02-18 16:43           ` Lorenzo Stoakes
2025-02-18 17:14             ` David Hildenbrand
2025-02-18 17:20               ` Lorenzo Stoakes
2025-02-18 17:25                 ` David Hildenbrand
2025-02-18 17:28                   ` Lorenzo Stoakes
2025-02-18 17:31                     ` David Hildenbrand
2025-02-25 15:54                     ` Vlastimil Babka
2025-02-25 16:31                       ` David Hildenbrand
2025-02-25 16:37                       ` Lorenzo Stoakes
2025-02-25 16:48                         ` David Hildenbrand
2025-02-19  8:25 ` Kalesh Singh
2025-02-19  8:35   ` Kalesh Singh
2025-02-19  9:15     ` Lorenzo Stoakes
2025-02-19 17:32     ` Liam R. Howlett
2025-02-19  9:03   ` Lorenzo Stoakes
2025-02-19  9:15     ` David Hildenbrand
2025-02-19  9:17       ` Lorenzo Stoakes
2025-02-19 18:52         ` Kalesh Singh
2025-02-19 19:20           ` Lorenzo Stoakes
2025-02-19 20:56             ` Kalesh Singh
2025-02-20  8:51               ` Lorenzo Stoakes
2025-02-20  8:57                 ` David Hildenbrand
2025-02-20  9:04                   ` Lorenzo Stoakes
2025-02-20  9:23                     ` David Hildenbrand
2025-02-20  9:47                       ` Lorenzo Stoakes
2025-02-20 10:03                         ` David Hildenbrand
2025-02-20 10:15                           ` Lorenzo Stoakes
2025-02-20 12:44                             ` David Hildenbrand
2025-02-20 13:18                               ` Lorenzo Stoakes
2025-02-20 16:21                                 ` Suren Baghdasaryan
2025-02-20 18:08                                   ` Kalesh Singh
2025-02-21 11:04                                     ` Lorenzo Stoakes
2025-02-21 17:24                                       ` Kalesh Singh
2025-02-20  9:22                 ` Vlastimil Babka
2025-02-20  9:53                   ` Lorenzo Stoakes

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=fbfae348-909b-48fa-9083-67696b02f15e@suse.cz \
    --to=vbabka@suse.cz \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=jyescas@google.com \
    --cc=kaleshsingh@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=paulmck@kernel.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox