The proc-empty-vm test is implemented for x86_64 and fails to build
for other architectures. Rather then emitting a compiler error it
would be preferable to only build the test on supported architectures.
Mark proc-empty-vm as a test for x86_64 and customise to the Makefile
to build it only when building for this target architecture.
Fixes: 5bc73bb3451b ("proc: test how it holds up with mapping'less process")
Signed-off-by: Punit Agrawal <punit.agrawal(a)bytedance.com>
---
tools/testing/selftests/proc/Makefile | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/proc/Makefile b/tools/testing/selftests/proc/Makefile
index cd95369254c0..6b31439902af 100644
--- a/tools/testing/selftests/proc/Makefile
+++ b/tools/testing/selftests/proc/Makefile
@@ -1,14 +1,18 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+# When ARCH not overridden for crosscompiling, lookup machine
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
CFLAGS += -Wall -O2 -Wno-unused-function
CFLAGS += -D_GNU_SOURCE
LDFLAGS += -pthread
-TEST_GEN_PROGS :=
+TEST_GEN_PROGS_x86_64 += proc-empty-vm
+
TEST_GEN_PROGS += fd-001-lookup
TEST_GEN_PROGS += fd-002-posix-eq
TEST_GEN_PROGS += fd-003-kthread
TEST_GEN_PROGS += proc-loadavg-001
-TEST_GEN_PROGS += proc-empty-vm
TEST_GEN_PROGS += proc-pid-vm
TEST_GEN_PROGS += proc-self-map-files-001
TEST_GEN_PROGS += proc-self-map-files-002
--
2.30.2
The 2022 update to the Arm architecture includes a number of additions
of generic data processing features, covering the base architecture, SVE
and SME. Other than SME these are all simple features which introduce no
architectural state so we simply need to expose hwcaps for them. This
series covers these simple features. Since the SME updates do introduce
new architectural state for which we must add new ABI they will be
handled in a separate series.
Mark Brown (6):
arm64/hwcap: Add support for FEAT_CSSC
kselftest/arm64: Add FEAT_CSSC to the hwcap selftest
arm64/hwcap: Add support for FEAT_RPRFM
kselftest/arm64: Add FEAT_RPRFM to the hwcap test
arm64/hwcap: Add support for SVE 2.1
kselftest/arm64: Add SVE 2.1 to hwcap test
Documentation/arm64/elf_hwcaps.rst | 9 +++++++
Documentation/arm64/sve.rst | 1 +
arch/arm64/include/asm/hwcap.h | 3 +++
arch/arm64/include/uapi/asm/hwcap.h | 3 +++
arch/arm64/kernel/cpufeature.c | 5 ++++
arch/arm64/kernel/cpuinfo.c | 3 +++
arch/arm64/tools/sysreg | 12 ++++++++-
tools/testing/selftests/arm64/abi/hwcap.c | 32 +++++++++++++++++++++++
8 files changed, 67 insertions(+), 1 deletion(-)
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.30.2
Hi.
First of all, I hope you are fine and the same for your relatives.
This contribution fixes a bug where the byte before the destination address can
be reset when a page fault occurs in strncpy_from_kernel_nofault() while copying
the first byte from the source address.
This bug leaded to kernel panic if a pointer containing the modified address is
dereferenced as the pointer does not contain a correct addresss.
To fix this bug, we simply reset the current destination byte in a case of a
page fault.
The proposed fix was tested and validated inside a VM:
root@vm-amd64:~# ./share/linux/tools/testing/selftests/bpf/test_progs --name varlen
...
#222 varlen:OK
Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
Without the patch, the test will fail:
root@vm-amd64:~# ./share/linux/tools/testing/selftests/bpf/test_progs --name varlen
...
#222 varlen:FAIL
Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
If you see any way to improve this contribution, feel free to share.
Alban Crequy (2):
maccess: fix writing offset in case of fault in
strncpy_from_kernel_nofault()
selftests: bpf: add a test when bpf_probe_read_kernel_str() returns
EFAULT
mm/maccess.c | 2 +-
tools/testing/selftests/bpf/prog_tests/varlen.c | 7 +++++++
tools/testing/selftests/bpf/progs/test_varlen.c | 5 +++++
3 files changed, 13 insertions(+), 1 deletion(-)
Best regards and thank you in advance.
--
2.25.1
[
At this point everything is done and I will start putting this work into a
git tree and into linux-next with the intention of sending it during the
next merge window.
I intend to focus the next several weeks on more intensive QA to look at
error flows and other things. Hopefully including syzkaller if I'm lucky
]
iommufd is the user API to control the IOMMU subsystem as it relates to
managing IO page tables that point at user space memory.
It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO
container) which is the VFIO specific interface for a similar idea.
We see a broad need for extended features, some being highly IOMMU device
specific:
- Binding iommu_domain's to PASID/SSID
- Userspace IO page tables, for ARM, x86 and S390
- Kernel bypassed invalidation of user page tables
- Re-use of the KVM page table in the IOMMU
- Dirty page tracking in the IOMMU
- Runtime Increase/Decrease of IOPTE size
- PRI support with faults resolved in userspace
Many of these HW features exist to support VM use cases - for instance the
combination of PASID, PRI and Userspace IO Page Tables allows an
implementation of DMA Shared Virtual Addressing (vSVA) within a
guest. Dirty tracking enables VM live migration with SRIOV devices and
PASID support allow creating "scalable IOV" devices, among other things.
As these features are fundamental to a VM platform they need to be
uniformly exposed to all the driver families that do DMA into VMs, which
is currently VFIO and VDPA.
The pre-v1 series proposed re-using the VFIO type 1 data structure,
however it was suggested that if we are doing this big update then we
should also come with an improved data structure that solves the
limitations that VFIO type1 has. Notably this addresses:
- Multiple IOAS/'containers' and multiple domains inside a single FD
- Single-pin operation no matter how many domains and containers use
a page
- A fine grained locking scheme supporting user managed concurrency for
multi-threaded map/unmap
- A pre-registration mechanism to optimize vIOMMU use cases by
pre-pinning pages
- Extended ioctl API that can manage these new objects and exposes
domains directly to user space
- domains are sharable between subsystems, eg VFIO and VDPA
The bulk of this code is a new data structure design to track how the
IOVAs are mapped to PFNs.
iommufd intends to be general and consumable by any driver that wants to
DMA to userspace. From a driver perspective it can largely be dropped in
in-place of iommu_attach_device() and provides a uniform full feature set
to all consumers.
As this is a larger project this series is the first step. This series
provides the iommfd "generic interface" which is designed to be suitable
for applications like DPDK and VMM flows that are not optimized to
specific HW scenarios. It is close to being a drop in replacement for the
existing VFIO type 1 and supports existing qemu based VM flows.
Several follow-on series are being prepared:
- Patches integrating with qemu in native mode:
https://github.com/yiliu1765/qemu/commits/qemu-iommufd-6.0-rc2
- A completed integration with VFIO now exists that covers "emulated" mdev
use cases now, and can pass testing with qemu/etc in compatability mode:
https://github.com/jgunthorpe/linux/commits/vfio_iommufd
- A draft providing system iommu dirty tracking on top of iommufd,
including iommu driver implementations:
https://github.com/jpemartins/linux/commits/x86-iommufd
This pairs with patches for providing a similar API to support VFIO-device
tracking to give a complete vfio solution:
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com/
- Userspace page tables aka 'nested translation' for ARM and Intel iommu
drivers:
https://github.com/nicolinc/iommufd/commits/iommufd_nesting
- "device centric" vfio series to expose the vfio_device FD directly as a
normal cdev, and provide an extended API allowing dynamically changing
the IOAS binding:
https://github.com/yiliu1765/iommufd/commits/iommufd-v6.0-rc2-nesting-0901
- Drafts for PASID and PRI interfaces are included above as well
Overall enough work is done now to show the merit of the new API design
and at least draft solutions to many of the main problems.
Several people have contributed directly to this work: Eric Auger, Joao
Martins, Kevin Tian, Lu Baolu, Nicolin Chen, Yi L Liu. Many more have
participated in the discussions that lead here, and provided ideas. Thanks
to all!
The v1/v2 iommufd series has been used to guide a large amount of preparatory
work that has now been merged. The general theme is to organize things in
a way that makes injecting iommufd natural:
- VFIO live migration support with mlx5 and hisi_acc drivers.
These series need a dirty tracking solution to be really usable.
https://lore.kernel.org/kvm/20220224142024.147653-1-yishaih@nvidia.com/https://lore.kernel.org/kvm/20220308184902.2242-1-shameerali.kolothum.thodi…
- Significantly rework the VFIO gvt mdev and remove struct
mdev_parent_ops
https://lore.kernel.org/lkml/20220411141403.86980-1-hch@lst.de/
- Rework how PCIe no-snoop blocking works
https://lore.kernel.org/kvm/0-v3-2cf356649677+a32-intel_no_snoop_jgg@nvidia…
- Consolidate dma ownership into the iommu core code
https://lore.kernel.org/linux-iommu/20220418005000.897664-1-baolu.lu@linux.…
- Make all vfio driver interfaces use struct vfio_device consistently
https://lore.kernel.org/kvm/0-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nv…
- Remove the vfio_group from the kvm/vfio interface
https://lore.kernel.org/kvm/0-v3-f7729924a7ea+25e33-vfio_kvm_no_group_jgg@n…
- Simplify locking in vfio
https://lore.kernel.org/kvm/0-v2-d035a1842d81+1bf-vfio_group_locking_jgg@nv…
- Remove the vfio notifiter scheme that faces drivers
https://lore.kernel.org/kvm/0-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidi…
- Improve the driver facing API for vfio pin/unpin pages to make the
presence of struct page clear
https://lore.kernel.org/kvm/20220723020256.30081-1-nicolinc@nvidia.com/
- Clean up in the Intel IOMMU driver
https://lore.kernel.org/linux-iommu/20220301020159.633356-1-baolu.lu@linux.…https://lore.kernel.org/linux-iommu/20220510023407.2759143-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220514014322.2927339-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220706025524.2904370-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220702015610.2849494-1-baolu.lu@linux…
- Rework s390 vfio drivers
https://lore.kernel.org/kvm/20220707135737.720765-1-farman@linux.ibm.com/
- Normalize vfio ioctl handling
https://lore.kernel.org/kvm/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_jgg@nvidi…
- VFIO API for dirty tracking (aka dma logging) managed inside a PCI
device, with mlx5 implementation
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com
- Introduce a struct device sysfs presence for struct vfio_device
https://lore.kernel.org/kvm/20220901143747.32858-1-kevin.tian@intel.com/
- Complete restructuring the vfio mdev model
https://lore.kernel.org/kvm/20220822062208.152745-1-hch@lst.de/
- Isolate VFIO container code in preperation for iommufd to provide an
alternative implementation of it all
https://lore.kernel.org/kvm/0-v1-a805b607f1fb+17b-vfio_container_split_jgg@…
This is about 215 patches applied since March, thank you to everyone
involved in all this work!
Currently there are a number of supporting series still in progress:
- Simplify and consolidate iommu_domain/device compatability checking
https://lore.kernel.org/linux-iommu/20220815181437.28127-1-nicolinc@nvidia.…
- Align iommu SVA support with the domain-centric model
https://lore.kernel.org/linux-iommu/20220826121141.50743-1-baolu.lu@linux.i…
- DMABUF exporter support for VFIO to allow PCI P2P with VFIO
https://lore.kernel.org/r/0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com
- Start to provide iommu_domain ops for power
https://lore.kernel.org/all/20220714081822.3717693-1-aik@ozlabs.ru/
However, these are not necessary for this series to advance.
This is on github: https://github.com/jgunthorpe/linux/commits/iommufd
v3:
- Rebase to v6.1-rc1
- Improve documentation
- Use EXPORT_SYMBOL_NS
- Fix W1, checkpatch stuff
- Revise pages.c to resolve the FIXMEs. Create a
interval_tree_double_span_iter which allows a simple expression of the
previously problematic algorithms
- Consistently use the word 'access' instead of user to refer to an
access from an in-kernel user (eg vfio mdev)
- Support two forms of rlimit accounting and make the vfio compatible one
the default in compatability mode (following series)
- Support old VFIO type1 by disabling huge pages and implementing a
simple algorithm to split a struct iopt_area
- Full implementation of access support, test coverage and optimizations
- Complete COPY to be able to copy across contiguous areas. Improve
all the algorithms around contiguous areas with a dedicated iterator
- Functional ENFORCED_COHERENT support
- Support multi-device groups
- Lots of smaller changes (the interdiff is 5k lines)
v2: https://lore.kernel.org/r/0-v2-f9436d0bde78+4bb-iommufd_jgg@nvidia.com
- Rebase to v6.0-rc3
- Improve comments
- Change to an iterative destruction approach to avoid cycles
- Near rewrite of the vfio facing implementation, supported by a complete
implementation on the vfio side
- New IOMMU_IOAS_ALLOW_IOVAS API as discussed. Allows userspace to
assert that ranges of IOVA must always be mappable. To be used by a VMM
that has promised a guest a certain availability of IOVA. May help
guide PPC's multi-window implementation.
- Rework how unmap_iova works, user can unmap the whole ioas now
- The no-snoop / wbinvd support is implemented
- Bug fixes
- Test suite improvements
- Lots of smaller changes (the interdiff is 3k lines)
v1: https://lore.kernel.org/r/0-v1-e79cd8d168e8+6-iommufd_jgg@nvidia.com
Jason Gunthorpe (13):
iommu: Add IOMMU_CAP_ENFORCE_CACHE_COHERENCY
interval-tree: Add a utility to iterate over spans in an interval tree
iommufd: File descriptor, context, kconfig and makefiles
kernel/user: Allow user::locked_vm to be usable for iommufd
iommufd: PFN handling for iopt_pages
iommufd: Algorithms for PFN storage
iommufd: Data structure to provide IOVA to PFN mapping
iommufd: IOCTLs for the io_pagetable
iommufd: Add a HW pagetable object
iommufd: Add kAPI toward external drivers for physical devices
iommufd: Add kAPI toward external drivers for kernel access
iommufd: vfio container FD ioctl compatibility
iommufd: Add a selftest
Kevin Tian (1):
iommufd: Overview documentation
Lu Baolu (1):
iommu: Add device-centric DMA ownership interfaces
.clang-format | 3 +
Documentation/userspace-api/index.rst | 1 +
.../userspace-api/ioctl/ioctl-number.rst | 1 +
Documentation/userspace-api/iommufd.rst | 222 ++
MAINTAINERS | 10 +
drivers/iommu/Kconfig | 1 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/amd/iommu.c | 2 +
drivers/iommu/intel/iommu.c | 4 +
drivers/iommu/iommu.c | 116 +-
drivers/iommu/iommufd/Kconfig | 24 +
drivers/iommu/iommufd/Makefile | 13 +
drivers/iommu/iommufd/device.c | 744 +++++++
drivers/iommu/iommufd/double_span.h | 98 +
drivers/iommu/iommufd/hw_pagetable.c | 57 +
drivers/iommu/iommufd/io_pagetable.c | 1143 +++++++++++
drivers/iommu/iommufd/io_pagetable.h | 240 +++
drivers/iommu/iommufd/ioas.c | 390 ++++
drivers/iommu/iommufd/iommufd_private.h | 273 +++
drivers/iommu/iommufd/iommufd_test.h | 85 +
drivers/iommu/iommufd/main.c | 417 ++++
drivers/iommu/iommufd/pages.c | 1803 +++++++++++++++++
drivers/iommu/iommufd/selftest.c | 711 +++++++
drivers/iommu/iommufd/vfio_compat.c | 443 ++++
include/linux/interval_tree.h | 50 +
include/linux/iommu.h | 18 +
include/linux/iommufd.h | 101 +
include/linux/sched/user.h | 2 +-
include/uapi/linux/iommufd.h | 330 +++
kernel/user.c | 1 +
lib/Kconfig | 4 +
lib/interval_tree.c | 132 ++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/iommu/.gitignore | 2 +
tools/testing/selftests/iommu/Makefile | 11 +
tools/testing/selftests/iommu/config | 2 +
tools/testing/selftests/iommu/iommufd.c | 1715 ++++++++++++++++
37 files changed, 9145 insertions(+), 27 deletions(-)
create mode 100644 Documentation/userspace-api/iommufd.rst
create mode 100644 drivers/iommu/iommufd/Kconfig
create mode 100644 drivers/iommu/iommufd/Makefile
create mode 100644 drivers/iommu/iommufd/device.c
create mode 100644 drivers/iommu/iommufd/double_span.h
create mode 100644 drivers/iommu/iommufd/hw_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.h
create mode 100644 drivers/iommu/iommufd/ioas.c
create mode 100644 drivers/iommu/iommufd/iommufd_private.h
create mode 100644 drivers/iommu/iommufd/iommufd_test.h
create mode 100644 drivers/iommu/iommufd/main.c
create mode 100644 drivers/iommu/iommufd/pages.c
create mode 100644 drivers/iommu/iommufd/selftest.c
create mode 100644 drivers/iommu/iommufd/vfio_compat.c
create mode 100644 include/linux/iommufd.h
create mode 100644 include/uapi/linux/iommufd.h
create mode 100644 tools/testing/selftests/iommu/.gitignore
create mode 100644 tools/testing/selftests/iommu/Makefile
create mode 100644 tools/testing/selftests/iommu/config
create mode 100644 tools/testing/selftests/iommu/iommufd.c
base-commit: 247f34f7b80357943234f93f247a1ae6b6c3a740
--
2.38.0
Dzień dobry,
zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów.
Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci.
Możemy porozmawiać w najbliższym czasie?
Pozdrawiam
Adam Charachuta
commit b5ba705c2608 ("selftests/vm: enable running select groups of tests")
unintentionally reversed the ordering of some of the lines of
run_vmtests.sh that calculate values based on system configuration.
Importantly, $hpgsize_MB is determined from $hpgsize_KB, but this later
value is not read from /proc/meminfo until later, causing userfaultfd
tests to incorrectly fail since $half_ufd_size_MB will always be 0.
Switch these statements around into proper order to fix the invocation
of the userfaultfd tests that use $half_ufd_size_MB.
Suggested-by: Nico Pache <npache(a)redhat.com>
Signed-off-by: Joel Savitz <jsavitz(a)redhat.com>
---
tools/testing/selftests/vm/run_vmtests.sh | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/vm/run_vmtests.sh b/tools/testing/selftests/vm/run_vmtests.sh
index fff00bb77086..ce52e4f5ff21 100755
--- a/tools/testing/selftests/vm/run_vmtests.sh
+++ b/tools/testing/selftests/vm/run_vmtests.sh
@@ -82,16 +82,6 @@ test_selected() {
fi
}
-# Simple hugetlbfs tests have a hardcoded minimum requirement of
-# huge pages totaling 256MB (262144KB) in size. The userfaultfd
-# hugetlb test requires a minimum of 2 * nr_cpus huge pages. Take
-# both of these requirements into account and attempt to increase
-# number of huge pages available.
-nr_cpus=$(nproc)
-hpgsize_MB=$((hpgsize_KB / 1024))
-half_ufd_size_MB=$((((nr_cpus * hpgsize_MB + 127) / 128) * 128))
-needmem_KB=$((half_ufd_size_MB * 2 * 1024))
-
# get huge pagesize and freepages from /proc/meminfo
while read -r name size unit; do
if [ "$name" = "HugePages_Free:" ]; then
@@ -102,6 +92,16 @@ while read -r name size unit; do
fi
done < /proc/meminfo
+# Simple hugetlbfs tests have a hardcoded minimum requirement of
+# huge pages totaling 256MB (262144KB) in size. The userfaultfd
+# hugetlb test requires a minimum of 2 * nr_cpus huge pages. Take
+# both of these requirements into account and attempt to increase
+# number of huge pages available.
+nr_cpus=$(nproc)
+hpgsize_MB=$((hpgsize_KB / 1024))
+half_ufd_size_MB=$((((nr_cpus * hpgsize_MB + 127) / 128) * 128))
+needmem_KB=$((half_ufd_size_MB * 2 * 1024))
+
# set proper nr_hugepages
if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
nr_hugepgs=$(cat /proc/sys/vm/nr_hugepages)
--
2.31.1
Hello,
This patch series implements IOCTL on the pagemap procfs file to get the
information about the page table entries (PTEs). The following operations
are supported in this ioctl:
- Get the information if the pages are soft-dirty, file mapped, present
or swapped.
- Clear the soft-dirty PTE bit of the pages.
- Get and clear the soft-dirty PTE bit of the pages atomically.
Soft-dirty PTE bit of the memory pages can be read by using the pagemap
procfs file. The soft-dirty PTE bit for the whole memory range of the
process can be cleared by writing to the clear_refs file. There are other
methods to mimic this information entirely in userspace with poor
performance:
- The mprotect syscall and SIGSEGV handler for bookkeeping
- The userfaultfd syscall with the handler for bookkeeping
Some benchmarks can be seen here[1]. This series adds features that weren't
present earlier:
- There is no atomic get soft-dirty PTE bit status and clear operation
possible.
- The soft-dirty PTE bit of only a part of memory cannot be cleared.
Historically, soft-dirty PTE bit tracking has been used in the CRIU
project. The procfs interface is enough for finding the soft-dirty bit
status and clearing the soft-dirty bit of all the pages of a process.
We have the use case where we need to track the soft-dirty PTE bit for
only specific pages on demand. We need this tracking and clear mechanism
of a region of memory while the process is running to emulate the
getWriteWatch() syscall of Windows. This syscall is used by games to
keep track of dirty pages to process only the dirty pages.
The information related to pages if the page is file mapped, present and
swapped is required for the CRIU project[2][3]. The addition of the
required mask, any mask, excluded mask and return masks are also required
for the CRIU project[2].
The IOCTL returns the addresses of the pages which match the specific masks.
The page addresses are returned in struct page_region in a compact form.
The max_pages is needed to support a use case where user only wants to get
a specific number of pages. So there is no need to find all the pages of
interest in the range when max_pages is specified. The IOCTL returns when
the maximum number of the pages are found. The max_pages is optional. If
max_pages is specified, it must be equal or greater than the vec_size.
This restriction is needed to handle worse case when one page_region only
contains info of one page and it cannot be compacted. This is needed to
emulate the Windows getWriteWatch() syscall.
Some non-dirty pages get marked as dirty because of the kernel's
internal activity (such as VMA merging as soft-dirty bit difference isn't
considered while deciding to merge VMAs). The dirty bit of the pages is
stored in the VMA flags and in the per page flags. If any of these two bits
are set, the page is considered to be soft dirty. Suppose you have cleared
the soft dirty bit of half of VMA which will be done by splitting the VMA
and clearing soft dirty bit flag in the half VMA and the pages in it. Now
kernel may decide to merge the VMAs again. So the half VMA becomes dirty
again. This splitting/merging costs performance. The application receives
a lot of pages which aren't dirty in reality but marked as dirty.
Performance is lost again here. Also sometimes user doesn't want the newly
allocated memory to be marked as dirty. PAGEMAP_NO_REUSED_REGIONS flag
solves both the problems. It is used to not depend on the soft dirty flag
in the VMA flags. So VMA splitting and merging doesn't happen. It only
depends on the soft dirty bit of the individual pages. Thus by using this
flag, there may be a scenerio such that the new memory regions which are
just created, doesn't look dirty when seen with the IOCTL, but look dirty
when seen from procfs. This seems okay as the user of this flag know the
implication of using it.
[1] https://lore.kernel.org/lkml/54d4c322-cd6e-eefd-b161-2af2b56aae24@collabora…
[2] https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com/
[3] https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com/
Regards,
Muhammad Usama Anjum
Muhammad Usama Anjum (3):
fs/proc/task_mmu: update functions to clear the soft-dirty PTE bit
fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about
PTEs
selftests: vm: add pagemap ioctl tests
fs/proc/task_mmu.c | 396 +++++++++++-
include/uapi/linux/fs.h | 53 ++
tools/include/uapi/linux/fs.h | 53 ++
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 5 +-
tools/testing/selftests/vm/pagemap_ioctl.c | 681 +++++++++++++++++++++
6 files changed, 1156 insertions(+), 33 deletions(-)
create mode 100644 tools/testing/selftests/vm/pagemap_ioctl.c
--
2.30.2
When fixing up support for extra_context in the signal handling tests I
didn't notice that there is a TODO file in the directory which lists this
as a thing to be done. Since it's been done remove it from the list.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/signal/testcases/TODO | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/signal/testcases/TODO b/tools/testing/selftests/arm64/signal/testcases/TODO
index 110ff9fd195d..1f7fba8194fe 100644
--- a/tools/testing/selftests/arm64/signal/testcases/TODO
+++ b/tools/testing/selftests/arm64/signal/testcases/TODO
@@ -1,2 +1 @@
- Validate that register contents are saved and restored as expected.
-- Support and validate extra_context.
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.30.2