8f ("target/s390x: filter deprecated properties based on model
expansion type")
Signed-off-by: Collin Walling
[ david: add "Fixes", explain why fix is required now and reference to v3 ]
Signed-off-by: David Hildenbrand
Can you take a quick peek at
https://github
On 26.07.24 22:00, Collin Walling wrote:
On 7/26/24 3:57 PM, David Hildenbrand wrote:
On 25.07.24 20:39, Collin Walling wrote:
Currently, there is no way to execute the query-cpu-model-expansion
command to retrieve a comprehenisve list of deprecated properties, as
the result is dependent per
.g. host) to acquire the
full list of deprecated properties.
Additionally, the @deprecated-props array has been moved from the
CpuModelInfo struct to the CpuModelExpansionInfo struct, since the data
did not belong in the former.
Acked-by: David Hildenbrand
Suggested-by: Jiri Denemark
Signed-of
On 26.07.24 21:11, Collin Walling wrote:
On 7/26/24 3:15 AM, Markus Armbruster wrote:
Collin Walling writes:
On 7/25/24 3:39 AM, David Hildenbrand wrote:
On 25.07.24 09:35, Markus Armbruster wrote:
Markus Armbruster writes:
[...]
Arguments that are silently ignored is bad interface
to copy from the 8xx approach of
supporting such unusual ways of mapping hugetlb folios aware that it gets
tricky once multiple page tables are involved.
Signed-off-by: David Hildenbrand
---
arch/powerpc/mm/pgtable.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/mm/pgtable.c b
Sharing page tables between processes but falling back to per-MM page
table locks cannot possibly work.
So, let's make sure that we do have split PMD locks by adding a new
Kconfig option and letting that depend on CONFIG_SPLIT_PMD_PTLOCKS.
Signed-off-by: David Hildenbrand
---
fs/Kconfig
Let's clean that up a bit and prepare for depending on
CONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options.
More cleanups would be reasonable (like the arch-specific "depends on"
for CONFIG_SPLIT_PTE_PTLOCKS), but we'll leave that for another day.
Signed-off-by: David Hildenbrand
---
a
Let's clean that up a bit and prepare for depending on
CONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options.
More cleanups would be reasonable (like the arch-specific "depends on"
for CONFIG_SPLIT_PTE_PTLOCKS), but we'll leave that for another day.
Signed-off-by: David Hildenbrand
---
a
to copy from the 8xx approach of
supporting such unusual ways of mapping hugetlb folios aware that it gets
tricky once multiple page tables are involved.
Signed-off-by: David Hildenbrand
---
arch/powerpc/mm/pgtable.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/mm/pgtable.c b
Sharing page tables between processes but falling back to per-MM page
table locks cannot possibly work.
So, let's make sure that we do have split PMD locks by adding a new
Kconfig option and letting that depend on CONFIG_SPLIT_PMD_PTLOCKS.
Signed-off-by: David Hildenbrand
---
fs/Kconfig
Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: "H. Peter Anvin"
Cc: Alexander Viro
Cc: Christian Brauner
David Hildenbrand (3):
mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig
options
mm/hugetlb: enforce that PMD PT sharing
Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: "H. Peter Anvin"
Cc: Alexander Viro
Cc: Christian Brauner
David Hildenbrand (3):
mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig
options
mm/hugetlb: enforce that PMD PT sharing
On 26.07.24 08:20, Chenyi Qiang wrote:
On 7/25/2024 10:04 PM, David Hildenbrand wrote:
Open
Implementing a RamDiscardManager to notify VFIO of page conversions
causes changes in semantics: private memory is treated as discarded (or
hot-removed) memory. This isn't aligned
On 26.07.24 07:02, Tian, Kevin wrote:
From: David Hildenbrand
Sent: Thursday, July 25, 2024 10:04 PM
Open
Implementing a RamDiscardManager to notify VFIO of page conversions
causes changes in semantics: private memory is treated as discarded (or
hot-removed) memory. This isn't aligned
Open
Implementing a RamDiscardManager to notify VFIO of page conversions
causes changes in semantics: private memory is treated as discarded (or
hot-removed) memory. This isn't aligned with the expectation of current
RamDiscardManager users (e.g. VFIO or live migration) who really
expect
On 25.07.24 09:35, Markus Armbruster wrote:
Markus Armbruster writes:
Collin Walling writes:
On 7/24/24 3:56 AM, Markus Armbruster wrote:
Collin Walling writes:
Let me try to explain the purpose of @deprecated-props and see if it
helps bring us closer to some semblance of a mutual
On 23.07.24 23:04, Peter Xu wrote:
On Tue, Jul 23, 2024 at 10:18:37AM +0200, David Hildenbrand wrote:
On 22.07.24 17:31, Peter Xu wrote:
On Mon, Jul 22, 2024 at 03:29:43PM +0200, David Hildenbrand wrote:
On 18.07.24 00:02, Peter Xu wrote:
This is an RFC series, so not yet for merging
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 22.07.24 17:31, Peter Xu wrote:
On Mon, Jul 22, 2024 at 03:29:43PM +0200, David Hildenbrand wrote:
On 18.07.24 00:02, Peter Xu wrote:
This is an RFC series, so not yet for merging. Please don't be scared by
the code changes: most of them are code movements only.
This series is based
On 18.07.24 00:02, Peter Xu wrote:
This is an RFC series, so not yet for merging. Please don't be scared by
the code changes: most of them are code movements only.
This series is based on the dax mprotect fix series here (while that one is
based on mm-unstable):
[PATCH v3 0/8] mm/mprotect:
begin) {
+if (!ranges_overlap(cur->phys_addr, cur->length, begin, length)) {
QTAILQ_REMOVE(>head, cur, next);
g_free(cur);
list->num--;
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 20.07.24 22:28, Steven Sistare wrote:
On 7/16/2024 5:19 AM, Igor Mammedov wrote:
On Sun, 30 Jun 2024 12:40:24 -0700
Steve Sistare wrote:
Allocate anonymous memory using mmap MAP_ANON or memfd_create depending
on the value of the anon-alloc machine property. This affects
On 18.07.24 17:56, Peter Xu wrote:
Steve,
On Sun, Jun 30, 2024 at 12:40:23PM -0700, Steve Sistare wrote:
What?
Thanks for trying out with the cpr-transfer series. I saw that that series
missed most of the cc list here, so I'm attaching the link here:
On 19.07.24 17:51, Jonathan Cameron wrote:
On Fri, 19 Jul 2024 17:07:35 +0200
David Hildenbrand wrote:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size
On 19.07.24 17:51, Jonathan Cameron wrote:
On Fri, 19 Jul 2024 17:07:35 +0200
David Hildenbrand wrote:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size
On 19.07.24 17:34, Mike Rapoport wrote:
On Fri, Jul 19, 2024 at 05:07:35PM +0200, David Hildenbrand wrote:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size
On 19.07.24 17:34, Mike Rapoport wrote:
On Fri, Jul 19, 2024 at 05:07:35PM +0200, David Hildenbrand wrote:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
- if (!nd_pa) {
- pr_err("Cannot find %zu bytes in any node (initial node:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
- if (!nd_pa) {
- pr_err("Cannot find %zu bytes in any node (initial node:
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Architectures that support NUMA duplicate the code that allocates
NODE_DATA on the node-local memory with slight variations in reporting
of the addresses where the memory was allocated.
Use x86 version as the basis for
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Architectures that support NUMA duplicate the code that allocates
NODE_DATA on the node-local memory with slight variations in reporting
of the addresses where the memory was allocated.
Use x86 version as the basis for
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
The stub functions in kernel/numa.c belong to mm/ rather than to kernel/
Signed-off-by: Mike Rapoport (Microsoft)
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
The stub functions in kernel/numa.c belong to mm/ rather than to kernel/
Signed-off-by: Mike Rapoport (Microsoft)
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
h
delete mode 100644 arch/s390/include/asm/mmzone.h
delete mode 100644 arch/x86/include/asm/mmzone.h
delete mode 100644 arch/x86/include/asm/mmzone_32.h
delete mode 100644 arch/x86/include/asm/mmzone_64.h
create mode 100644 include/asm-generic/mmzone.h
Nice!
Acked-by: David Hildenbrand
h
delete mode 100644 arch/s390/include/asm/mmzone.h
delete mode 100644 arch/x86/include/asm/mmzone.h
delete mode 100644 arch/x86/include/asm/mmzone_32.h
delete mode 100644 arch/x86/include/asm/mmzone_64.h
create mode 100644 include/asm-generic/mmzone.h
Nice!
Acked-by: David Hildenbrand
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Make definition of node_data match other architectures.
This will allow pulling declaration of node_data to the generic mm code in
the following commit.
Signed-off-by: Mike Rapoport (Microsoft)
---
Reviewed
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Make definition of node_data match other architectures.
This will allow pulling declaration of node_data to the generic mm code in
the following commit.
Signed-off-by: Mike Rapoport (Microsoft)
---
Reviewed
DE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
I was assuming we could get rid of __node_data->pglist.
But now I am confused where that is actually set.
Anyhow
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
DE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
I was assuming we could get rid of __node_data->pglist.
But now I am confused where that is actually set.
Anyhow
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 16.07.24 07:37, Borah, Chaitanya Kumar wrote:
Hello Pei,
Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
This mail is regarding a regression we are seeing in our CI runs[1] on
linux-next repository.
In version next-20240712[2], we saw the following
/properties/
+#populated with the model's enabled property set when delta changes
+#are applied. All deprecated properties are reported otherwise.
#
# Since: 2.8
##
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
memory: discard
currently blocked");
error_append_hint(errp, "Are you using assigned devices?\n");
goto out_free;
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
s? I guess it wouldn't be that bad
because disabling unsupported features will just work, even if the CPU
model is not aware of them.
So no strong opinion.
Just noting that libvirt cannot really rely on that information because
the behavior would change between QEMU versions? Maybe not an is
nd "Memory devices" queue ("mem"):
- Only one error message improvement that causes less confusion when
triggered from libvirt
--------
David Hildenbrand (1):
virtio-mem: improve error message when unplug of device fai
size" property.
Let's simply avoid talking about the "size" property and spell out that
some device memory is still plugged.
Message-ID: <20240416141426.588544-1-da...@redhat.com>
Tested-by: Mario Casquero
Cc: Liang Cong
Cc: Mario Casquero
Cc: "Michael S. Tsirkin"
On 04.07.24 23:30, Michael S. Tsirkin wrote:
Currently, if VIRTIO_BALLOON_F_FREE_PAGE_HINT is off but
VIRTIO_BALLOON_F_REPORTING is on, then the reporting vq
gets number 3 while spec says it's number 4.
It happens to work because the linux virtio pci driver
is *also* out of spec.
To fix:
1. add
what the API was supposed to do
in the 1st place. Compatibility with buggy hypervisors
is handled inside virtio-balloon, which is the only driver
making use of this facility, so far.
Signed-off-by: Michael S. Tsirkin
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
what the API was supposed to do
in the 1st place. Compatibility with buggy hypervisors
is handled inside virtio-balloon, which is the only driver
making use of this facility, so far.
Signed-off-by: Michael S. Tsirkin
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
;
+ }
vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 02.07.24 13:30, Alistair Popple wrote:
David Hildenbrand writes:
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow
On 02.07.24 13:46, Christoph Hellwig wrote:
On Tue, Jul 02, 2024 at 09:18:31AM +0200, David Hildenbrand wrote:
We have this comparably nasty vmf_insert_mixed() that FS dax abused to
insert into !VM_MIXED VMAs. Is that abuse now stopping and are there maybe
ways to get rid of vmf_insert_mixed
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map
On 02.07.24 01:47, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Longterm pinning of FS DAX pages should already be disallowed by
various pXX_devmap checks. However a future change will cause these
checks to be invalid for FS DAX pages so make
On 27.06.24 02:54, Alistair Popple wrote:
Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
creates a special devmap PTE entry for the pfn but does not take a
reference on the underlying struct page for the mapping. This is
because DAX page refcounts are treated specially, as
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
and take references as it would for a normally
t MADV_DONTDUMP, "
-"but dump_guest_core=off specified\n");
+"but dump-guest-core=off specified\n");
}
}
}
---
base-commit: 046a64b9801343e2e89eef10c7a48eec8d8c0d4f
change-id: 20240614-dump-7b73ab18c31a
Best regards,
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 27.06.24 02:54, Alistair Popple wrote:
Longterm pinning of FS DAX pages should already be disallowed by
various pXX_devmap checks. However a future change will cause these
checks to be invalid for FS DAX pages so make
folio_is_longterm_pinnable() return false for FS DAX pages.
Signed-off-by:
On 26.06.24 00:43, Andrew Morton wrote:
afaict we're in decent state to move this series into mm-stable. I've
tagged the following issues:
https://lkml.kernel.org/r/80532f73e52e2c21fdc9aac7bce24aefb76d11b0.ca...@linux.intel.com
On 26.06.24 00:43, Andrew Morton wrote:
afaict we're in decent state to move this series into mm-stable. I've
tagged the following issues:
https://lkml.kernel.org/r/80532f73e52e2c21fdc9aac7bce24aefb76d11b0.ca...@linux.intel.com
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
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
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
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 user
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
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
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
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
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 want
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
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
lude/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
ches.
[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/testing/sel
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 that on
() ->
__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, accor
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
: 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: John Hubbard
---
tools/testing
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: Jeff Xu
; 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
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: David
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
ng to rely on totalram_pages().
Signed-off-by: Wei Yang
CC: Jason Lunz
CC: Jeff Dike
Cc: Paolo 'Blaisorblade' Giarrusso
Cc: Alasdair G Kergon
Cc: Jens Axboe
CC: Andrew Morton
CC: Mike Rapoport (IBM)
CC: David Hildenbrand
---
A simple UML bootup test looks good.
---
arch/um/kernel/mem.c | 2 +
On 11.06.24 21:19, Andrew Morton wrote:
On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote:
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug
On 11.06.24 21:19, Andrew Morton wrote:
On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote:
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug
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 11.06.24 21:41, Tim Chen wrote:
On Fri, 2024-06-07 at 11:09 +0200, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug specific handling from generic_online_page
On 11.06.24 21:41, Tim Chen wrote:
On Fri, 2024-06-07 at 11:09 +0200, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug specific handling from generic_online_page
On 11.06.24 21:19, Andrew Morton wrote:
On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote:
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug
On 11.06.24 21:19, Andrew Morton wrote:
On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote:
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug specific handling from generic_online_page() to
__free_pages_core(), use adjust_managed_page_count
1 - 100 of 15109 matches
Mail list logo
