Commit 17de1e559cf1 ("selftests: clarify common error when running
gup_test") had most of its hunks dropped due to a conflict with another
patch accepted into Linux around the same time that implemented the same
behavior as a subset of other changes.
However, the remaining hunk defines the GUP_TEST_FILE macro without
making use of it. This patch makes use of the macro in the two relevant
places.
Furthermore, the above mentioned commit's log message erroneously describes
the changes that were dropped from the patch.
This patch corrects the record.
Fixes: 17de1e559cf1 ("selftests: clarify common error when running gup_test")
Signed-off-by: Joel Savitz <jsavitz(a)redhat.com>
---
tools/testing/selftests/vm/gup_test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/vm/gup_test.c b/tools/testing/selftests/vm/gup_test.c
index 6bb36ca71cb5..a309876d832f 100644
--- a/tools/testing/selftests/vm/gup_test.c
+++ b/tools/testing/selftests/vm/gup_test.c
@@ -209,7 +209,7 @@ int main(int argc, char **argv)
if (write)
gup.gup_flags |= FOLL_WRITE;
- gup_fd = open("/sys/kernel/debug/gup_test", O_RDWR);
+ gup_fd = open(GUP_TEST_FILE, O_RDWR);
if (gup_fd == -1) {
switch (errno) {
case EACCES:
@@ -224,7 +224,7 @@ int main(int argc, char **argv)
printf("check if CONFIG_GUP_TEST is enabled in kernel config\n");
break;
default:
- perror("failed to open /sys/kernel/debug/gup_test");
+ perror("failed to open " GUP_TEST_FILE);
break;
}
exit(KSFT_SKIP);
--
2.31.1
From: Ira Weiny <ira.weiny(a)intel.com>
While evaluating the possibility of defining a new type for pkeys within the
kernel I found a couple of minor bugs.
Because these patches clean up the return codes from system calls I'm sending
this out RFC hoping that users will speak up if anything breaks.
I'm not too concerned about pkey_free() because it is unlikely that anyone is
checking the return code. Interestingly enough, glibc recommends not calling
pkey_free() because it does not change the access rights to the key and may be
subsequently allocated again.[1][2]
The pkey_alloc() is more concerning. However, I checked the Chrome source and
it does not differentiate among the return codes and maps all errors into
kNoMemoryProtectionKey.
glibc says it returns ENOSYS if the system does not support pkeys but I don't
see where ENOSYS is returned? AFAICS it just returns what the kernel returns.
So it is probably up to user of glibc.
In addition I've enhanced the pkey tests to verify and test the changes.
Thanks to Rick Edgecombe and Sohil Mehta for internal review.
[1] Quote from manual/memory.texi:
Calling this function does not change the access rights of the freed
protection key. The calling thread and other threads may retain access
to it, even if it is subsequently allocated again. For this reason, it
is not recommended to call the @code{pkey_free} function.
[2] PKS had a similar issue and went to statically allocated keys instead.
Ira Weiny (6):
testing/pkeys: Add command line options
testing/pkeys: Don't use uninitialized variable
testing/pkeys: Add additional test for pkey_alloc()
pkeys: Lift pkey hardware check for pkey_alloc()
pkeys: Up level pkey_free() checks
pkeys: Change mm_pkey_free() to void
arch/powerpc/include/asm/pkeys.h | 18 ++---
arch/x86/include/asm/pkeys.h | 7 +-
include/linux/pkeys.h | 5 +-
mm/mprotect.c | 13 +++-
tools/testing/selftests/vm/pkey-helpers.h | 7 +-
tools/testing/selftests/vm/protection_keys.c | 75 +++++++++++++++++---
6 files changed, 86 insertions(+), 39 deletions(-)
base-commit: 874c8ca1e60b2c564a48f7e7acc40d328d5c8733
--
2.35.1
Before change:
make -C netfilter
TEST: performance
net,port [SKIP]
perf not supported
port,net [SKIP]
perf not supported
net6,port [SKIP]
perf not supported
port,proto [SKIP]
perf not supported
net6,port,mac [SKIP]
perf not supported
net6,port,mac,proto [SKIP]
perf not supported
net,mac [SKIP]
perf not supported
After change:
net,mac [ OK ]
baseline (drop from netdev hook): 2061098pps
baseline hash (non-ranged entries): 1606741pps
baseline rbtree (match on first field only): 1191607pps
set with 1000 full, ranged entries: 1639119pps
ok 8 selftests: netfilter: nft_concat_range.sh
Fixes: 611973c1e06f ("selftests: netfilter: Introduce tests for sets with range concatenation")
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Jie2x Zhou <jie2x.zhou(a)intel.com>
---
tools/testing/selftests/netfilter/nft_concat_range.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/netfilter/nft_concat_range.sh b/tools/testing/selftests/netfilter/nft_concat_range.sh
index b35010cc7f6a..a6991877e50c 100755
--- a/tools/testing/selftests/netfilter/nft_concat_range.sh
+++ b/tools/testing/selftests/netfilter/nft_concat_range.sh
@@ -31,7 +31,7 @@ BUGS="flush_remove_add reload"
# List of possible paths to pktgen script from kernel tree for performance tests
PKTGEN_SCRIPT_PATHS="
- ../../../samples/pktgen/pktgen_bench_xmit_mode_netif_receive.sh
+ ../../../../samples/pktgen/pktgen_bench_xmit_mode_netif_receive.sh
pktgen/pktgen_bench_xmit_mode_netif_receive.sh"
# Definition of set types:
--
2.34.1
This series is based on linux-next/akpm-base.
The series is split up like so:
- Patch 1 is a simple fixup which we should take in any case (even by itself).
- Patches 2-4 add the feature, basic support for it to the selftest, and docs.
- Patches 5-6 make the selftest configurable, so you can test one or the other
instead of always both. If we decide this is overcomplicated, we could just
drop these two patches and take the rest of the series.
Changelog:
v2->v3:
- Rebased onto linux-next/akpm-base, in order to be based on top of the
run_vmtests.sh refactor which was merged previously.
- Picked up some Reviewed-by's.
- Fixed ioctl definition (_IO instead of _IOWR), and stopped using
compat_ptr_ioctl since it is unneeded for ioctls which don't take a pointer.
- Removed the "handle_kernel_faults" bool, simplifying the code. The result is
logically equivalent, but simpler.
- Fixed userfaultfd selftest so it returns KSFT_SKIP appropriately.
- Reworded documentation per Shuah's feedback on v2.
- Improved example usage for userfaultfd selftest.
v1->v2:
- Add documentation update.
- Test *both* userfaultfd(2) and /dev/userfaultfd via the selftest.
Axel Rasmussen (6):
selftests: vm: add hugetlb_shared userfaultfd test to run_vmtests.sh
userfaultfd: add /dev/userfaultfd for fine grained access control
userfaultfd: selftests: modify selftest to use /dev/userfaultfd
userfaultfd: update documentation to describe /dev/userfaultfd
userfaultfd: selftests: make /dev/userfaultfd testing configurable
selftests: vm: add /dev/userfaultfd test cases to run_vmtests.sh
Documentation/admin-guide/mm/userfaultfd.rst | 40 ++++++++++-
Documentation/admin-guide/sysctl/vm.rst | 3 +
fs/userfaultfd.c | 76 ++++++++++++++++----
include/uapi/linux/userfaultfd.h | 4 ++
tools/testing/selftests/vm/run_vmtests.sh | 11 ++-
tools/testing/selftests/vm/userfaultfd.c | 66 ++++++++++++++---
6 files changed, 172 insertions(+), 28 deletions(-)
--
2.36.1.255.ge46751e96f-goog
--
Hello,
My name is Steve Dibenedetto.I apologize to have contacted you this way
without a direct relationship. There is an opportunity to collaborate
with me in the sourcing of some materials needed by our company for
production of the different medicines we are researching.
I'm aware that this might be totally outside your professional
specialization, but it will be a great source for generating extra
revenue. I discovered a manufacturer who can supply us at a lower rate
than our company's previous purchases.
I will give you more specific details when/if I receive feedback from
you showing interest.
Warm Regards
Steve Dibenedetto
Production & Control Manager,
Green Field Laboratories
Gothic House, Barker Gate,
Nottingham, NG1 1JU,
United Kingdom.