[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1762686301.git.lorenzo.stoakes@oracle.com>
Date: Sun, 9 Nov 2025 11:16:05 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: David Hildenbrand <david@...nel.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
Jann Horn <jannh@...gle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] mm: perform guard region install/remove under VMA lock
There is no reason why can't perform guard region operations under the VMA
lock, as long we take proper precautions to ensure that we do so in a safe
manner.
This is fine, as VMA lock acquisition is always best-effort, so if we are
unable to do so, we can simply fall back to using the mmap read lock.
Doing so will reduce mmap lock contention for callers performing guard
region operations and help establish a precedent of trying to use the VMA
lock where possible.
As part of this change we perform a trivial rename of page walk functions
which bypass safety checks (i.e. whether or not mm_walk_ops->install_pte is
specified) in order that we can keep naming consistent with the mm walk.
This is because we need to expose a VMA-specific walk that still allows us
to install PTE entries.
Lorenzo Stoakes (2):
mm: rename walk_page_range_mm()
mm/madvise: allow guard page install/remove under VMA lock
mm/internal.h | 5 ++-
mm/madvise.c | 110 ++++++++++++++++++++++++++++++++++++--------------
mm/pagewalk.c | 25 +++++++-----
3 files changed, 99 insertions(+), 41 deletions(-)
--
2.51.0
Powered by blists - more mailing lists