e);
Interesting, thanks!
"1" should work, because we use "0xff" to detect modifications.
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 21.08.24 17:59, Mina Almasry wrote:
On Wed, Aug 21, 2024 at 8:31 AM David Hildenbrand wrote:
Currently, running the charge_reserved_hugetlb.sh selftest we can
sometimes observe something like:
$ ./charge_reserved_hugetlb.sh -cgroup-v2
...
write_result is 0
After write
work as expected.
Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests")
Reported-by: Mario Casquero
Cc: Andrew Morton
Cc: Shuah Khan
Cc: Muchun Song
Cc: Mina Almasry
Signed-off-by: David Hildenbrand
---
.../selftests/mm/charge_reserved_hugetlb.sh
On 12.08.24 07:35, Dev Jain wrote:
On 8/11/24 14:38, David Hildenbrand wrote:
On 11.08.24 08:06, Dev Jain wrote:
On 8/11/24 00:22, David Hildenbrand wrote:
On 10.08.24 20:42, Dev Jain wrote:
On 8/9/24 19:17, David Hildenbrand wrote:
On 09.08.24 12:31, Dev Jain wrote:
As already being
On 11.08.24 08:06, Dev Jain wrote:
On 8/11/24 00:22, David Hildenbrand wrote:
On 10.08.24 20:42, Dev Jain wrote:
On 8/9/24 19:17, David Hildenbrand wrote:
On 09.08.24 12:31, Dev Jain wrote:
As already being done in __migrate_folio(), wherein we backoff if the
folio refcount is wrong, make
On 10.08.24 20:42, Dev Jain wrote:
On 8/9/24 19:17, David Hildenbrand wrote:
On 09.08.24 12:31, Dev Jain wrote:
As already being done in __migrate_folio(), wherein we backoff if the
folio refcount is wrong, make this check during the unmapping phase,
upon
the failure of which, the original
On 09.08.24 12:31, Dev Jain wrote:
As already being done in __migrate_folio(), wherein we backoff if the
folio refcount is wrong, make this check during the unmapping phase, upon
the failure of which, the original state of the PTEs will be restored and
the folio lock will be dropped via migrate_f
On 21.06.24 11:25, Quentin Perret wrote:
On Friday 21 Jun 2024 at 10:02:08 (+0200), David Hildenbrand wrote:
Thanks for the information. IMHO we really should try to find a common
ground here, and FOLL_EXCLUSIVE is likely not it :)
That's OK, IMO at least :-).
Thanks for reviving
On 21.06.24 10:54, Fuad Tabba wrote:
Hi David,
On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand wrote:
Again from that thread, one of most important aspects guest_memfd is that VMAs
are not required. Stating the obvious, lack of VMAs makes it really hard to
drive
swap, reclaim, migration
On 21.06.24 09:25, Ryan Roberts wrote:
On 20/06/2024 12:34, David Hildenbrand wrote:
On 20.06.24 11:04, Ryan Roberts wrote:
On 20/06/2024 01:26, Barry Song wrote:
From: Barry Song
Both Ryan and Chris have been utilizing the small test program to aid
in debugging and identifying issues with
Again from that thread, one of most important aspects guest_memfd is that VMAs
are not required. Stating the obvious, lack of VMAs makes it really hard to
drive
swap, reclaim, migration, etc. from code that fundamentally operates on VMAs.
: More broadly, no VMAs are required. The lack of sta
On 21.06.24 09:32, Quentin Perret wrote:
On Thursday 20 Jun 2024 at 20:18:14 (-0300), Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 03:47:23PM -0700, Elliot Berman wrote:
On Thu, Jun 20, 2024 at 11:29:56AM -0300, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David
On 21.06.24 01:54, Sean Christopherson wrote:
On Thu, Jun 20, 2024, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 01:30:29PM -0700, Sean Christopherson wrote:
I.e. except for blatant bugs, e.g. use-after-free, we need to be able to
guarantee
with 100% accuracy that there are no outstanding ma
On 20.06.24 22:30, Sean Christopherson wrote:
On Thu, Jun 20, 2024, David Hildenbrand wrote:
On 20.06.24 18:36, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
If we could disallow pinning any shared pages, that would make life a lot
easier, but I
On 20.06.24 18:04, Sean Christopherson wrote:
On Thu, Jun 20, 2024, David Hildenbrand wrote:
On 20.06.24 16:29, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad
On 20.06.24 18:36, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote:
If we could disallow pinning any shared pages, that would make life a lot
easier, but I think there were reasons for why we might require it. To
convert shared->private, simply un
On 20.06.24 16:29, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 04:01:08PM +0200, David Hildenbrand wrote:
On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
Hi,
On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig wrote:
On Wed, Jun 19
On 20.06.24 15:08, Mostafa Saleh wrote:
Hi David,
On Wed, Jun 19, 2024 at 09:37:58AM +0200, David Hildenbrand wrote:
Hi,
On 19.06.24 04:44, John Hubbard wrote:
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
grabbing shmem
On 20.06.24 15:55, Jason Gunthorpe wrote:
On Thu, Jun 20, 2024 at 09:32:11AM +0100, Fuad Tabba wrote:
Hi,
On Thu, Jun 20, 2024 at 5:11 AM Christoph Hellwig wrote:
On Wed, Jun 19, 2024 at 08:51:35AM -0300, Jason Gunthorpe wrote:
If you can't agree with the guest_memfd people on how to get th
On 20.06.24 11:04, Ryan Roberts wrote:
On 20/06/2024 01:26, Barry Song wrote:
From: Barry Song
Both Ryan and Chris have been utilizing the small test program to aid
in debugging and identifying issues with swap entry allocation. While
a real or intricate workload might be more suitable for ass
Yes, and I think we might have to revive that discussion, unfortunately.
I started thinking about this, but did not reach a conclusion. Sharing
my thoughts.
The minimum we might need to make use of guest_memfd (v1 or v2 ;) ) not
just for private memory should be:
(1) Have private + shared parts
On 20.06.24 03:53, Huang, Ying wrote:
Barry Song <21cn...@gmail.com> writes:
From: Barry Song
Both Ryan and Chris have been utilizing the small test program to aid
in debugging and identifying issues with swap entry allocation. While
a real or intricate workload might be more suitable for ass
If the memory can't be accessed by the CPU then it shouldn't be mapped
into a PTE in the first place. The fact you made userspace faults
(only) work is nifty but still an ugly hack to get around the fact you
shouldn't be mapping in the first place.
We already have ZONE_DEVICE/DEVICE_PRIVATE to ha
On 19.06.24 11:11, Fuad Tabba wrote:
Hi John and David,
Thank you for your comments.
On Wed, Jun 19, 2024 at 8:38 AM David Hildenbrand wrote:
Hi,
On 19.06.24 04:44, John Hubbard wrote:
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we wa
Hi,
On 19.06.24 04:44, John Hubbard wrote:
On 6/18/24 5:05 PM, Elliot Berman wrote:
In arm64 pKVM and QuIC's Gunyah protected VM model, we want to support
grabbing shmem user pages instead of using KVM's guestmemfd. These
hypervisors provide a different isolation model than the CoCo
implementat
On 18.06.24 23:29, John Hubbard wrote:
On 6/18/24 1:54 PM, David Hildenbrand wrote:
On 18.06.24 22:14, John Hubbard wrote:
On 6/17/24 11:56 PM, David Hildenbrand wrote:
On 18.06.24 04:24, John Hubbard wrote:
...
...
I can update the commit description with some of the above, if it helps
On 18.06.24 22:14, John Hubbard wrote:
On 6/17/24 11:56 PM, David Hildenbrand wrote:
On 18.06.24 04:24, John Hubbard wrote:
...
diff --git a/tools/testing/selftests/mm/seal_elf.c
b/tools/testing/selftests/mm/seal_elf.c
index f2babec79bb6..27bf2f84231d 100644
--- a/tools/testing/selftests/mm
a snapshot
over from ./usr/include/linux/prctl.h, as per the approach we settled on
in [1].
[1] commit e076eaca5906 ("selftests: break the dependency upon local
header files")
Cc: David Hildenbrand
Signed-off-by: John Hubbard
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
PU arches.
[1] commit e076eaca5906 ("selftests: break the dependency upon local
header files")
Fixes: 4926c7a52de7 ("selftest mm/mseal memory sealing")
Cc: Jeff Xu
Cc: David Hildenbrand
Signed-off-by: John Hubbard
---
tools/testing/selftests/mm/mseal_test.c | 2 +-
tools/testin
On 14.06.24 20:02, John Hubbard wrote:
On 6/14/24 5:41 AM, David Hildenbrand wrote:
On 14.06.24 14:28, David Hildenbrand wrote:
On 14.06.24 04:30, John Hubbard wrote:
The selftests/mm build isn't exactly "broken", according to the current
documentation, which still claims th
() ->
__mmap_and_merge_range -> ksm_merge-> ksm_get_full_scans,
start_scans = ksm_get_full_scans() will return an error.
Therefore, the value of ksm_full_scans_fd needs to be
initialized before calling test_child_ksm in the child process.
Signed-off-by: aigourensheng
---
Acked-by: David Hildenbrand
On 14.06.24 14:28, David Hildenbrand wrote:
On 14.06.24 04:30, John Hubbard wrote:
The selftests/mm build isn't exactly "broken", according to the current
documentation, which still claims that one must run "make headers",
before building the kselftests. However, acc
the dependency upon local
header files")
Cc: David Hildenbrand
Cc: Jeff Xu
Signed-off-by: John Hubbard
---
Lovely
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
st.c:26:18: error: use of undeclared identifier 'PR_SET_MDWE'
mdwe_test.c:38:18: error: use of undeclared identifier 'PR_GET_MDWE'
Fix these errors by adding the missing items to vm_util.h, and include
vm_util.h from mdwe_test.c.
Cc: David Hildenbrand
Signed-off-by: Joh
e076eaca5906 ("selftests: break the dependency upon local
header files")
Cc: David Hildenbrand
Signed-off-by: John Hubbard
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 14.06.24 04:30, John Hubbard wrote:
Now that the test macros are factored out into their final location, and
simplified, it's time to rename TEST_END_CHECK to something that
represents its new functionality: REPORT_TEST_PASS.
Cc: David Hildenbrand
Reviewed-by: Jeff Xu
Tested-by: Je
; they can simply return.
2. PKEY* items. We cannot, unfortunately use pkey-helpers.h. The best we
can do is to factor out these few items into mseal_helpers.h.
3. These tests still need their own definition of u64, so also move that
to the header file.
Cc: Jeff Xu
Cc: David Hildenbrand
Signed-off
files that
require __NR_mseal to include from the correct location. The way to do
so is to include instead of just .
[1] commit e076eaca5906 ("selftests: break the dependency upon local
header files")
Fixes: 4926c7a52de7 ("selftest mm/mseal memory sealing")
Cc: Jeff Xu
Cc:
On 13.06.24 23:27, John Hubbard wrote:
On 6/12/24 7:11 PM, John Hubbard wrote:
On 6/12/24 1:24 AM, David Hildenbrand wrote:
On 11.06.24 22:54, John Hubbard wrote:
On 6/11/24 2:36 AM, David Hildenbrand wrote:
On 08.06.24 04:10, John Hubbard wrote:
...
You remembered correctly, but the
On 11.06.24 22:54, John Hubbard wrote:
On 6/11/24 2:36 AM, David Hildenbrand wrote:
On 08.06.24 04:10, John Hubbard wrote:
Eventually, once the build succeeds on a sufficiently old distro, the
idea is to delete $(KHDR_INCLUDES) from the selftests/mm build, and then
after that, from selftests
On 08.06.24 04:10, John Hubbard wrote:
Eventually, once the build succeeds on a sufficiently old distro, the
idea is to delete $(KHDR_INCLUDES) from the selftests/mm build, and then
after that, from selftests/lib.mk and all of the other selftest builds.
For now, this series merely achieves a cle
On 11.06.24 08:25, John Hubbard wrote:
On 6/10/24 9:45 PM, Jeff Xu wrote:
On Mon, Jun 10, 2024 at 9:34 PM John Hubbard wrote:
On 6/10/24 9:21 PM, Jeff Xu wrote:
Hi
On Fri, Jun 7, 2024 at 7:10 PM John Hubbard wrote:
Eventually, once the build succeeds on a sufficiently old distro, the
ide
ge pagecache folio generated, please provide a
filesystem supporting large folio\n");
base-commit: d97496ca23a2d4ee80b7302849404859d9058bcd
Acked-by: David Hildenbrand
I was wondering if we should factor that out into a mm-selftest helper
function, but that can be done later.
--
Cheers,
David / dhildenb
On 06.06.24 22:18, Pankaj Raghav (Samsung) wrote:
On Thu, Jun 06, 2024 at 05:57:21PM +0200, David Hildenbrand wrote:
On 06.06.24 17:56, David Hildenbrand wrote:
On 06.06.24 15:58, Pankaj Raghav (Samsung) wrote:
From: Pankaj Raghav
create_pagecache_thp_and_fd() in split_huge_page_test.c used
On 06.06.24 17:56, David Hildenbrand wrote:
On 06.06.24 15:58, Pankaj Raghav (Samsung) wrote:
From: Pankaj Raghav
create_pagecache_thp_and_fd() in split_huge_page_test.c used the
variable dummy to perform mmap read.
However, this test was skipped even on XFS which has large folio
support
On 06.06.24 15:58, Pankaj Raghav (Samsung) wrote:
From: Pankaj Raghav
create_pagecache_thp_and_fd() in split_huge_page_test.c used the
variable dummy to perform mmap read.
However, this test was skipped even on XFS which has large folio
support. The issue was compiler (gcc 13.2.0) was optimizi
ed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 24.05.24 11:31, Donet Tom wrote:
On 5/24/24 12:31, David Hildenbrand wrote:
On 24.05.24 08:43, Ritesh Harjani (IBM) wrote:
David Hildenbrand writes:
dropping sta...@vger.kernel.org
On 24.05.24 04:57, Andrew Morton wrote:
On Thu, 23 May 2024 22:40:25 +0200 David Hildenbrand
wrote
On 24.05.24 08:43, Ritesh Harjani (IBM) wrote:
David Hildenbrand writes:
dropping sta...@vger.kernel.org
On 24.05.24 04:57, Andrew Morton wrote:
On Thu, 23 May 2024 22:40:25 +0200 David Hildenbrand wrote:
You have sta...@vger.kernel.org in the mail headers, so I assume you're
prop
On 24.05.24 04:57, Andrew Morton wrote:
On Thu, 23 May 2024 22:40:25 +0200 David Hildenbrand wrote:
You have sta...@vger.kernel.org in the mail headers, so I assume you're
proposing this for backporting. When doing this, please include
Cc:
in the changelog footers and also include a
On 23.05.24 21:13, Andrew Morton wrote:
On Thu, 23 May 2024 01:39:05 -0500 Donet Tom wrote:
Commit 1b151e2435fc ("block: Remove special-casing of compound
pages") caused a change in behaviour when releasing the pages
if the buffer does not start at the beginning of the page. This
was because t
On 08.05.24 14:58, Audra Mitchell wrote:
On Wed, May 08, 2024 at 09:39:10AM +0200, David Hildenbrand wrote:
On 07.05.24 21:55, Audra Mitchell wrote:
Currently if we request a feature that is not set in the Kernel
config we fail silently and return the available features. However, the
On 07.05.24 21:55, Audra Mitchell wrote:
Currently if we request a feature that is not set in the Kernel
config we fail silently and return the available features. However, the
documentation indicates we should return an EINVAL.
I assume you are referencing
"EINVAL The API version requested in
On 02.05.24 16:28, Peter Xu wrote:
On Thu, May 02, 2024 at 10:52:59AM +0200, David Hildenbrand wrote:
Let's document why hugetlb still uses folio_mapcount() and is prone to
leaking memory between processes, for example using vmsplice() that
still uses FOLL_GET.
More details can be found
larly care about
these vmsplice() leaks for hugetlb -- in contrast to ordinary memory.
[1] https://lore.kernel.org/all/8b42a24d-caf0-46ef-9e15-0f88d47d2...@redhat.com/
Suggested-by: Peter Xu
Signed-off-by: David Hildenbrand
---
mm/hugetlb.c | 7 +++
1 file changed, 7 insertions(+)
diff
pass:769 fail:0 xfail:8 xpass:0 skip:1 error:0
$ echo $?
0
[1] https://lore.kernel.org/all/8b42a24d-caf0-46ef-9e15-0f88d47d2...@redhat.com/
Signed-off-by: David Hildenbrand
---
tools/testing/selftests/mm/cow.c | 106 +--
1 file changed, 71 insertions(+
-0f88d47d2...@redhat.com/
Cc: Andrew Morton
Cc: Muchun Song
Cc: Shuah Khan
David Hildenbrand (2):
selftests: mm: cow: flag vmsplice() hugetlb tests as XFAIL
mm/hugetlb: document why hugetlb uses folio_mapcount() for COW reuse
decisions
mm/hugetlb.c | 7 ++
too
commit a12083d721d7
("mm/gup: handle hugepd for follow_page()"), whereby R/O pinning was not
able to make progress in all cases, because unsharing logic was not
provided with the VMA to decide at some point that long-term R/O pinning
a !anon page is fine.
Cc: Andrew Morton
Cc: Shuah Khan
Shivansh, do you speak for CRIU? Are you able to comment on whether CRIU
supports checkpointing an app that uses uffd?
I do not speak for CRIU - I'm just a user (and hopefully a future contributor),
but not a maintainer or owner. I can however comment on whether CRIU supports
checkpointing an
We further recently added a new UFFD_FEATURE_WP_ASYNC feature as part of
[2], because getting soft-dirty return reliable results in some cases turned
out rather hard to fix.
But it sounds like the current soft-dirty semantic is sufficient for CRIU on
other arches? If I understood correctly f
9,5 +209,5 @@ int main(int argc, char **argv)
close(pagemap_fd);
- return ksft_exit_pass();
+ ksft_finished();
}
--
2.25.1
Guess that makes sense independent of all the other stuff?
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 19.04.24 18:30, Mike Rapoport wrote:
On Fri, Apr 19, 2024 at 11:45:14AM +0200, David Hildenbrand wrote:
On 19.04.24 10:33, Shivansh Vij wrote:
On 19/04/2024 08:43, Ryan Roberts wrote:
Hi All,
This series adds uffd write-protect and soft-dirty tracking support for arm64. I
consider the
On 19.04.24 10:33, Shivansh Vij wrote:
(Sorry about the previous HTML email, accidentally used the wrong email client)
Hey All,
On 19/04/2024 08:43, Ryan Roberts wrote:
Hi All,
This series adds uffd write-protect and soft-dirty tracking support for arm64. I
consider the soft-dirty support (p
On 15.04.24 16:19, Alexander Gordeev wrote:
On Fri, Apr 12, 2024 at 10:43:29AM +0200, David Hildenbrand wrote:
Hi David,
tools/testing/selftests/kvm/Makefile | 1 +
.../kvm/s390x/shared_zeropage_test.c | 110 ++
2 files changed, 111 insertions(+)
create
ff-by: David Hildenbrand
---
To get it right this time, test the relevant cases.
v3 of fixes are at:
https://lore.kernel.org/all/20240411161441.910170-1-da...@redhat.com/T/#u
---
tools/testing/selftests/kvm/Makefile | 1 +
.../kvm/s390x/shared_zeropage_test.c
On 04.04.24 21:04, Mark Brown wrote:
On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
arch-specific thingies here.
It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
patch out of my
On 04.04.24 01:34, Deepak Gupta wrote:
VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow stack VMA.
This patch changes checks of VM_SHADOW_STACK flag in generic code to call
to a function `vma_is_shadow_stack` which will return true if its a
shadow stack vma and default stub (when suppo
On 04.04.24 01:34, Deepak Gupta wrote:
VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma.
x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only.
arm64 follows same path (see links)
To keep things simple, RISC-V follows the same.
This patch adds `ss` fo
ich additionally required
memfd.h).
[1] https://lore.kernel.org/all/783a4178-1dec-4e30-989a-5174b8176...@redhat.com/
Cc: David Hildenbrand
Cc: Mark Brown
Cc: Muhammad Usama Anjum
Cc: Suren Baghdasaryan
Cc: Peter Zijlstra
Signed-off-by: John Hubbard
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
redhat.com/
Cc: David Hildenbrand
Cc: Mark Brown
Cc: Muhammad Usama Anjum
Cc: Suren Baghdasaryan
Cc: Peter Zijlstra
Signed-off-by: John Hubbard
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
elftests: soft-dirty: add test for mprotect")
Cc: Keith Busch
Cc: Zi Yan
Cc: Peter Xu
Cc: Yang Shi
Cc: Andrea Arcangeli
Cc: Nadav Amit
Cc: David Hildenbrand
Cc: Andrew Morton
Signed-off-by: Vitaly Chikunov
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 11.03.24 15:35, Peter Xu wrote:
On Mon, Mar 11, 2024 at 10:31:41AM +0100, David Hildenbrand wrote:
On 09.03.24 20:12, Mirsad Todorovac wrote:
Hi,
Routine run of the test in net-next gave also this mm unit error.
root@defiant:tools/testing/selftests/mm# ./uffd-unit-tests
Testing UFFDIO_API
On 09.03.24 20:12, Mirsad Todorovac wrote:
Hi,
Routine run of the test in net-next gave also this mm unit error.
root@defiant:tools/testing/selftests/mm# ./uffd-unit-tests
Testing UFFDIO_API (with syscall)... done
Testing UFFDIO_API (with /dev/userfaultfd)... done
Testing register-ioctls on ano
i++) {
page_owner = get_page_owner(page_ext);
- page_owner->order = 0;
+ page_owner->order = new_order;
page_ext = page_ext_next(page_ext);
}
page_ext_put(page_ext);
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
(folio_test_pmd_mappable(folio))
+ ttu_flags |= TTU_SPLIT_HUGE_PMD;
+
/*
* Anon pages need migration entries to preserve them, but file
* pages can simply be left unmapped, then faulted back on demand.
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 14.02.24 11:50, Ryan Roberts wrote:
On 13/02/2024 22:31, Zi Yan wrote:
On 13 Feb 2024, at 17:21, David Hildenbrand wrote:
On 13.02.24 22:55, Zi Yan wrote:
From: Zi Yan
Hi all,
File folio supports any order and multi-size THP is upstreamed[1], so both
file and anonymous folios can be &g
On 13.02.24 22:55, Zi Yan wrote:
From: Zi Yan
It adds a new_order parameter to set new page order in page owner.
It prepares for upcoming changes to support split huge page to any
lower order.
Signed-off-by: Zi Yan
---
include/linux/page_owner.h | 10 +-
mm/huge_memory.c
-by: Zi Yan
---
Nothing jumped at me.
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
void split_page_owner(struct page *page,
- unsigned short order)
+ int order)
I assume this will fit into a single line now.
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
split_page_memcg(head, order);
if (folio_test_anon(folio) && folio_test_swapcache(folio)) {
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 13.02.24 22:55, Zi Yan wrote:
From: Zi Yan
Hi all,
File folio supports any order and multi-size THP is upstreamed[1], so both
file and anonymous folios can be >0 order. Currently, split_huge_page()
only splits a huge page to order-0 pages, but splitting to orders higher than
0 is going to b
On 13.02.24 23:05, Luis Chamberlain wrote:
On Tue, Feb 13, 2024 at 04:55:18PM -0500, Zi Yan wrote:
From: Zi Yan
Order-1 folio is not supported because _deferred_list, which is used by
partially mapped folios, is stored in subpage 2 and an order-1 folio only
has subpage 0 and 1.
The LBS patche
On 25.01.24 18:07, Deepak Gupta wrote:
On Thu, Jan 25, 2024 at 09:18:07AM +0100, David Hildenbrand wrote:
On 25.01.24 07:21, de...@rivosinc.com wrote:
From: Deepak Gupta
x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow
stack VMA. VM_SHADOW_STACK is thus not possible on
On 25.01.24 07:21, de...@rivosinc.com wrote:
From: Deepak Gupta
x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow
stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may
need a way to encode shadow stack on 32bit and 64bit both and they may
encode this in
On 25.01.24 07:21, de...@rivosinc.com wrote:
From: Deepak Gupta
VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma.
x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only.
arm64 follows same path
https://lore.kernel.org/lkml/20231009-arm64-gcs-v6-12-78e
On 13.12.23 23:01, John Hubbard wrote:
On 12/13/23 01:59, David Hildenbrand wrote:
...
Another variation though, would be to run "make headers", and snapshot
some of those files into tools/include.
^ this is what I had in mind
If you're writing a test that needs some new fanc
On 13.12.23 06:55, John Hubbard wrote:
On 12/12/23 21:52, John Hubbard wrote:
On 12/12/23 19:58, Muhammad Usama Anjum wrote:
...
Oh, this sounds like it would work nicely. No more "make headers"
required (hooray!). Instead, the new approach would be "selftests are
allowed to include from tools/
On 11.12.23 21:11, John Hubbard wrote:
On 12/11/23 12:01, Mark Brown wrote:
On Mon, Dec 11, 2023 at 07:00:32PM +0100, David Hildenbrand wrote:
On 11.12.23 18:32, Mark Brown wrote:
On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
https://lkml.kernel.org/r
On 11.12.23 18:32, Mark Brown wrote:
On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
(3) avoids dirtying the tree as a "make headers_install" would, but it also
means that each test that makes use of new uapi has to update the relevant
headers (what people worki
Further, the tests are closely related to the given kernel version, they are
not some completely separate tests.
Note that there's a general desire for the tests to *run* with older
kernels and use whatever feature test mechanisms exist to skip tests
that won't run. That's often needed anyway f
On 11.12.23 17:15, Suren Baghdasaryan wrote:
On Mon, Dec 11, 2023 at 4:24 AM Mark Brown wrote:
On Mon, Dec 11, 2023 at 01:03:27PM +0100, David Hildenbrand wrote:
On 11.12.23 12:15, Mark Brown wrote:
This is linux-next. I pasted the commands used to build and sent links
to a full build
On 11.12.23 12:15, Mark Brown wrote:
On Sun, Dec 10, 2023 at 07:04:19PM -0800, Suren Baghdasaryan wrote:
On Sun, Dec 10, 2023 at 5:01 PM Suren Baghdasaryan wrote:
Thanks for reporting! I'll try that later today.
Just to clarify, are you using mm-unstable and if so, has it been
rebased since
On 08.12.23 16:14, Peter Zijlstra wrote:
On Fri, Nov 03, 2023 at 01:22:54PM +0100, David Hildenbrand wrote:
On 03.11.23 13:16, Peter Zijlstra wrote:
On Tue, Jun 06, 2023 at 12:16:37AM -0700, John Hubbard wrote:
As per a discussion with Muhammad Usama Anjum [1], the following is how
one is
from parent into child
# [RUN] Basic COW after fork() ... with PTE-mapped THP
ok 5 No leak from parent into child
Reported-by: Nico Pache
Fixes: f4b5fd6946e2 ("selftests/vm: anon_cow: THP tests")
Signed-off-by: David Hildenbrand
---
tools/testing/selftests/mm/cow.c | 3 +
On 05.12.23 05:46, Suren Baghdasaryan wrote:
On Mon, Dec 4, 2023 at 10:44 AM Suren Baghdasaryan wrote:
On Mon, Dec 4, 2023 at 10:27 AM David Hildenbrand wrote:
On 04.12.23 17:35, Suren Baghdasaryan wrote:
On Mon, Dec 4, 2023 at 1:27 AM Ryan Roberts wrote:
On 04/12/2023 04:09, Suren
On 04.12.23 17:35, Suren Baghdasaryan wrote:
On Mon, Dec 4, 2023 at 1:27 AM Ryan Roberts wrote:
On 04/12/2023 04:09, Suren Baghdasaryan wrote:
On Sat, Dec 2, 2023 at 2:11 AM David Hildenbrand wrote:
On 02.12.23 09:04, Ryan Roberts wrote:
On 01/12/2023 20:47, David Hildenbrand wrote:
On
On 02.12.23 09:04, Ryan Roberts wrote:
On 01/12/2023 20:47, David Hildenbrand wrote:
On 01.12.23 10:29, Ryan Roberts wrote:
On 21/11/2023 17:16, Suren Baghdasaryan wrote:
Add tests for new UFFDIO_MOVE ioctl which uses uffd to move source
into destination buffer while checking the contents of
On 01.12.23 10:29, Ryan Roberts wrote:
On 21/11/2023 17:16, Suren Baghdasaryan wrote:
Add tests for new UFFDIO_MOVE ioctl which uses uffd to move source
into destination buffer while checking the contents of both after
the move. After the operation the content of the destination buffer
should ma
after_madv
ifneq ($(ARCH),arm64)
-TEST_GEN_PROGS += soft-dirty
+TEST_GEN_FILES += soft-dirty
endif
ifeq ($(ARCH),x86_64)
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 14.11.23 21:05, Mark Brown wrote:
Since multiple architectures have support for shadow stacks and we need to
select support for this feature in several places in the generic code
provide a generic config option that the architectures can select.
Suggested-by: David Hildenbrand
Signed-off-by
1 - 100 of 135 matches
Mail list logo
