[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1752497324.git.lorenzo.stoakes@oracle.com>
Date: Mon, 14 Jul 2025 14:00:35 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
David Hildenbrand <david@...hat.com>, Vlastimil Babka <vbabka@...e.cz>,
Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Jeff Xu <jeffxu@...omium.org>
Subject: [PATCH 0/5] mseal cleanups
Perform a number of cleanups to the mseal logic. Firstly, VM_SEALED is
treated differently from every other VMA flag, it really doesn't make sense
to do this and complicates logic, so we start by making this consistent
with everything else.
Next we place the madvise logic where it belongs - in mm/madvise.c. It
really makes no sense to abstract this elsewhere. In doing so, we go to
great lengths to explain very clearly the previously very confusing logic
as to what sealed mappings are impacted here.
We abstract out and explain the 'are there are any gaps in this range in
the mm?' check being performed as a prerequisite to mseal being performed,
and finally we simplify the actual mseal logic which is really quite
straightforward.
Lorenzo Stoakes (5):
mm/mseal: always define VM_SEALED
mm/mseal: move madvise() logic to mm/madvise.c
mm/mseal: small cleanups
mm/mseal: separate out and simplify VMA gap check
mm/mseal: rework mseal apply logic
include/linux/mm.h | 6 +-
mm/madvise.c | 62 +++++++++++-
mm/mseal.c | 161 +++++--------------------------
mm/vma.c | 18 ++++
mm/vma.h | 26 +----
tools/testing/vma/vma_internal.h | 6 +-
6 files changed, 116 insertions(+), 163 deletions(-)
--
2.50.1
Powered by blists - more mailing lists