OBE_EVENTS -> UPROBES.
>
> Fixes: efe99fabeb11b ("selftests/mm: add test about uprobe pte be orphan
> during vma merge")
> Reported-by: Aishwarya
> Closes:
> https://lore.kernel.org/all/20250610103729.72440-1-aishwarya@arm.com/
> Tested-by: Aishwarya TCV
> Tested-by : Donet Tom
> Reviewed-by: Lorenzo Stoakes
> Signed-off-by: Dev Jain
Reviewed-by: Pedro Falcato
--
Pedro
On Thu, Jun 12, 2025 at 11:58:21AM +0530, Dev Jain wrote:
>
> On 11/06/25 6:00 pm, Pedro Falcato wrote:
> > On Wed, Jun 11, 2025 at 05:40:11PM +0530, Dev Jain wrote:
> > > If CONFIG_UPROBES is not set, a merge subtest fails:
> > >
> > > Failure lo
On Wed, Jun 11, 2025 at 05:40:11PM +0530, Dev Jain wrote:
> If CONFIG_UPROBES is not set, a merge subtest fails:
>
> Failure log:
>
> 7151 12:46:54.627936 # # # RUN
> merge.handle_uprobe_upon_merged_vma ...
> 7152 12:46:54.639014 # # f /sys/bus/event_source/devices/uprobe/type
>
lore.kernel.org/linux-mm/20250610103729.72440-1-aishwarya@arm.com/
Signed-off-by: Pedro Falcato
---
tools/testing/selftests/mm/merge.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mm/merge.c
b/tools/testing/selftests/mm/merge.c
index bbae66fc5038..cc26480
On Thu, Aug 29, 2024 at 09:43:51PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add sealing test to cover mmap for
> Expand/shrink across vmas.
> Reuse the same address in !MAP_FIXED case.
>
> Signed-off-by: Jeff Xu
> ---
> tools/testing/selftests/mm/mseal_test.c | 125 +
On Thu, Aug 29, 2024 at 09:43:50PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add a testcase to cover all sealed madvise type.
>
> Signed-off-by: Jeff Xu
> ---
> tools/testing/selftests/mm/mseal_test.c | 108 +++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
On Thu, Aug 29, 2024 at 09:43:49PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add check for vma size, prot bits and error return.
>
> Signed-off-by: Jeff Xu
> ---
> tools/testing/selftests/mm/mseal_test.c | 398
> 1 file changed, 332 insertions(+), 66 deletion
On Thu, Aug 29, 2024 at 09:43:48PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> This series increase the test coverage of mseal_test by:
>
> Add check for vma_size, prot, and error code for existing tests.
> Add more testcases for madvise, munmap, mmap and mremap to cover
> sealing in dif
+CC vma reviewers
On Wed, Aug 28, 2024 at 10:55:21PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> mmap(MAP_FIXED) should return EPERM when memory is sealed.
>
> Fixes: 4205a39e06da ("mm/munmap: replace can_modify_mm with can_modify_vma")
Thank you for the patch!
This Fixes: is wrong, the
96948e28e03 Mon Sep 17 00:00:00 2001
From: Pedro Falcato
Date: Thu, 22 Aug 2024 00:20:19 +0100
Subject: [PATCH] selftests/mm: Fix mseal's length
We accidentally msealed too much, which could overrun and try to mseal
other regions. This seems to be harmless (at least on top-down
architectures
On Wed, Aug 21, 2024 at 6:28 PM Pedro Falcato wrote:
> > ok. Then this test should be as below ? (need to add PROT_NONE page
> > before and after)
> > size = get_vma_size(ptr, &prot);
> > FAIL_TEST_IF_FALSE(size == 2 * page_size);
> > FAIL_TEST_IF_FALS
On Wed, Aug 21, 2024 at 5:27 PM Jeff Xu wrote:
>
> On Wed, Aug 21, 2024 at 9:20 AM Pedro Falcato wrote:
> >
> > On Wed, Aug 21, 2024 at 4:56 PM Jeff Xu wrote:
> > >
> > > Hi Pedro
> > >
> > > On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato
On Wed, Aug 21, 2024 at 5:16 PM Jeff Xu wrote:
>
> On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato wrote:
> >
> > We were doing an extra mmap tree traversal just to check if the entire
> > range is modifiable. This can be done when we iterate through the VMAs
> >
On Wed, Aug 21, 2024 at 4:56 PM Jeff Xu wrote:
>
> Hi Pedro
>
> On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato wrote:
> >
> > Add more mseal traversal tests across VMAs, where we could possibly
> > screw up sealing checks. These test more across-vma traversal for
&g
On Mon, Aug 19, 2024 at 9:15 PM Liam R. Howlett wrote:
>
> * Pedro Falcato [240816 20:18]:
> > Move can_modify_vma to vma.h so it can be inlined properly (with
> > the intent to remove can_modify_mm callsites).
> >
> > Signed-off-by: Pedro Falcato
On Sat, Aug 17, 2024 at 1:18 AM Pedro Falcato wrote:
> @@ -983,6 +1019,41 @@ static void test_seal_munmap_vma_with_gap(bool seal)
> REPORT_TEST_PASS();
> }
>
> +static void test_seal_munmap_partial_across_vmas(bool seal)
> +{
> + void *ptr;
> +
Add more mseal traversal tests across VMAs, where we could possibly
screw up sealing checks. These test more across-vma traversal for
mprotect, munmap and madvise. Particularly, we test for the case where a
regular VMA is followed by a sealed VMA.
Signed-off-by: Pedro Falcato
---
tools/testing
With no more users in the tree, we can finally remove can_modify_mm().
Signed-off-by: Pedro Falcato
---
mm/internal.h | 14 --
mm/mseal.c| 21 -
2 files changed, 35 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 1db320650539..3b738b0ad893
an is_ro_anon() due to arch_vma_access_permitted()
looking at e.g pkeys registers (with extra branches) in some
architectures.
This patch allows for partial madvise success when finding a sealed VMA,
which historically has been allowed in Linux.
Signed-off-by: Pedro Falcato
---
mm/internal.
Delegate all can_modify checks to the proper places. Unmap checks are
done in do_unmap (et al). The source VMA check is done purposefully
before unmapping, to keep the original mseal semantics.
Signed-off-by: Pedro Falcato
---
mm/mremap.c | 32 ++--
1 file changed, 6
Avoid taking an extra trip down the mmap tree by checking the vmas
directly. mprotect (per POSIX) tolerates partial failure.
Signed-off-by: Pedro Falcato
---
mm/mprotect.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index
Move can_modify_vma to vma.h so it can be inlined properly (with
the intent to remove can_modify_mm callsites).
Signed-off-by: Pedro Falcato
---
mm/mseal.c | 17 -
mm/vma.h | 28
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/mm
We were doing an extra mmap tree traversal just to check if the entire
range is modifiable. This can be done when we iterate through the VMAs
instead.
Signed-off-by: Pedro Falcato
---
mm/mmap.c | 11 +--
mm/vma.c | 19 ---
2 files changed, 13 insertions(+), 17 deletions
On Wed, Aug 7, 2024 at 7:03 PM Jeff Xu wrote:
>
> test_seal_mremap_move_dontunmap use 0 as new_addr, 0 indicates
> allocating a new memory.
> test_seal_mremap_move_dontunmap_anyaddr uses any arbitrary address as
> a new address.
No, MREMAP_DONTUNMAP uses the address you pass as a hint, aka you'r
Adjust the mseal test's plan.
Signed-off-by: Pedro Falcato
---
Andrew, please squash this small fix into "selftests/mm: Add mseal test for
no-discard madvise".
Thank you!
tools/testing/selftests/mm/mseal_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
On Wed, Aug 7, 2024 at 7:58 PM Andrew Morton wrote:
>
> On Wed, 7 Aug 2024 18:33:35 +0100 Pedro Falcato
> wrote:
>
> > is_madv_discard did its check wrong. MADV_ flags are not bitwise,
> > they're normal sequential numbers. So, for instance:
> >
statement instead.
Cc: sta...@vger.kernel.org
Fixes: 8be7258aad44 ("mseal: add mseal syscall")
Signed-off-by: Pedro Falcato
---
mm/mseal.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mm/mseal.c b/mm/mseal.c
index bf783bba8ed..15bba28acc0 100644
--- a/
Add an mseal test for madvise() operations that aren't considered
"discard" (e.g purely advisory ops such as MADV_RANDOM).
Signed-off-by: Pedro Falcato
---
tools/testing/selftests/mm/mseal_test.c | 34 +
1 file changed, 34 insertions(+)
diff --git
).
Based on Linus's tree and taken from my mseal depessimization series[1].
[1]:
https://lore.kernel.org/all/20240806212808.1885309-1-pedro.falc...@gmail.com/
Pedro Falcato (2):
mseal: Fix is_madv_discard()
selftests/mm: Add mseal test for no-discard madvise
mm/ms
On Wed, Aug 7, 2024 at 4:35 PM wrote:
> /* shrink from 4 pages to 2 pages. */
> - ret2 = mremap(ptr, size, 2 * page_size, 0, 0);
> + ret2 = sys_mremap(ptr, size, 2 * page_size, 0, 0);
> if (seal) {
> - FAIL_TEST_IF_FALSE(ret2 == MAP_FAILED);
> +
On Fri, Apr 19, 2024 at 2:22 AM Jeff Xu wrote:
> The overhead is likely to grow linearly with the number of VMA, since
> it takes time to retrieve VMA's metadata.
>
> Let's use one data sample to look at impact:
>
> Test: munmap 1000 memory range, each memory range has 1 VMA
>
> syscall__ vm
On Fri, Apr 19, 2024 at 4:44 AM wrote:
>
> From: Jeff Xu
>
> fix compile warning reported by test robot
>
> Signed-off-by: Jeff Xu
> Reported-by: kernel test robot
> Closes: https://lore.kernel.org/r/202404190226.ofjoewv8-...@intel.com/
> ---
> tools/testing/selftests/mm/mseal_test.c | 3 +--
>
On Fri, Feb 2, 2024 at 5:59 PM Jeff Xu wrote:
>
> On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt wrote:
> >
> > Jeff Xu wrote:
> >
> > > Even without free.
> > > I personally do not like the heap getting sealed like that.
> > >
> > > Component A.
> > > p=malloc(4096);
> > > writing something to p.
On Thu, Dec 14, 2023 at 6:07 PM Stephen Röttger wrote:
>
> On Thu, Dec 14, 2023 at 2:31 AM Linus Torvalds
> wrote:
> >
> > On Wed, 13 Dec 2023 at 16:36, Jeff Xu wrote:
> > >
> > >
> > > > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is
> > > > ok"?
> > > >
> > > The MADV_DO
On Thu, Oct 19, 2023 at 6:30 PM Jeff Xu wrote:
>
> Hi Pedro
>
> Some followup on mmap() + mprotect():
>
> On Wed, Oct 18, 2023 at 11:20 AM Jeff Xu wrote:
> >
> > On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato
> > wrote:
> > >
> > > &
On Tue, Oct 17, 2023 at 10:34 PM Jeff Xu wrote:
>
> On Tue, Oct 17, 2023 at 8:30 AM Pedro Falcato wrote:
> >
> > On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
> > >
> > > On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> >
On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
>
> On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > supported NX since the release of kernel version 2.6.8 in August 2004 [1].
>
> This seems
37 matches
Mail list logo
