The HID test cases actually run tests using the run-hid-tools-tests.sh
script. However, if installed with "make install", the run-hid-tools-tests.sh
script will not be copied over, resulting in the following error message.
make -C tools/testing/selftests/ TARGETS=hid install \
INSTALL_PATH=$KSFT_INSTALL_PATH
cd $KSFT_INSTALL_PATH
./run_kselftest.sh -c hid
selftests: hid: hid-core.sh
bash: ./run-hid-tools-tests.sh: No such file or directory
So add the run-hid-tools-tests.sh script to the TEST_FILES in the Makefile.
Signed-off-by: Yun Lu <luyun(a)kylinos.cn>
---
tools/testing/selftests/hid/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/hid/Makefile b/tools/testing/selftests/hid/Makefile
index 72be55ac4bdf..38ae31bb07b5 100644
--- a/tools/testing/selftests/hid/Makefile
+++ b/tools/testing/selftests/hid/Makefile
@@ -17,6 +17,8 @@ TEST_PROGS += hid-tablet.sh
TEST_PROGS += hid-usb_crash.sh
TEST_PROGS += hid-wacom.sh
+TEST_FILES := run-hid-tools-tests.sh
+
CXX ?= $(CROSS_COMPILE)g++
HOSTPKG_CONFIG := pkg-config
--
2.27.0
If you wish to utilise a pidfd interface to refer to the current process
(from the point of view of userland - from the kernel point of view - the
thread group leader), it is rather cumbersome, requiring something like:
int pidfd = pidfd_open(getpid(), 0);
...
close(pidfd);
Or the equivalent call opening /proc/self. It is more convenient to use a
sentinel value to indicate to an interface that accepts a pidfd that we
simply wish to refer to the current process.
This series introduces such a sentinel, PIDFD_SELF, which can be passed as
the pidfd in this instance rather than having to establish a dummy fd for
this purpose.
The only pidfd interface where this is particularly useful is
process_madvise(), which provides the motivation for this series. However,
as this is a general interface, we ensure that all pidfd interfaces can
handle this correctly.
We ensure that pidfd_send_signal() and pidfd_getfd() work correctly, and
assert as much in selftests. All other interfaces except setns() will work
implicitly with this new interface, however it doesn't make sense to test
waitid(P_PIDFD, ...) as waiting on ourselves is a blocking operation.
In the case of setns() we explicitly disallow use of PIDFD_SELF as it
doesn't make sense to obtain the namespaces of our own process, and it
would require work to implement this functionality there that would be of
no use.
We also do not provide the ability to utilise PIDFD_SELF in ordinary fd
operations such as open() or poll(), as this would require extensive work
and be of no real use.
Lorenzo Stoakes (3):
pidfd: refactor pidfd_get_pid/to_pid() and de-duplicate pid lookup
pidfd: add PIDFD_SELF sentinel to refer to own process
selftests: pidfd: add tests for PIDFD_SELF
include/linux/pid.h | 43 +++++++++++-
include/uapi/linux/pidfd.h | 3 +
kernel/exit.c | 3 +-
kernel/nsproxy.c | 1 +
kernel/pid.c | 70 +++++++++++++------
kernel/signal.c | 26 ++-----
tools/testing/selftests/pidfd/pidfd.h | 5 ++
.../selftests/pidfd/pidfd_getfd_test.c | 38 ++++++++++
.../selftests/pidfd/pidfd_setns_test.c | 6 ++
tools/testing/selftests/pidfd/pidfd_test.c | 13 ++++
10 files changed, 165 insertions(+), 43 deletions(-)
--
2.46.2
"Eric W. Biederman" <ebiederm(a)xmission.com> writes:
> Kees Cook <kees(a)kernel.org> writes:
>> I'm not super comfortable doing this regardless of bprm->fdpath; that
>> seems like too many cases getting changed. Can we just leave it as
>> depending on bprm->fdpath?
I was recommending that because I did not expect that there was any
widespread usage of aliasing of binary names using symlinks.
I realized today that on debian there are many aliases
of binaries created with the /etc/alternatives mechanism.
So there is much wider exposure to problems than I would have
supposed.
So I remove any objections to making the new code conditional on bprm->fdpath.
Eric
Currently, the second bridge command overwrites the first one.
Fix this by adding this VID to the interface behind $swp2.
The one_bridge_two_pvids() test intends to check that there is no
leakage of traffic between bridge ports which have a single VLAN - the
PVID VLAN.
Because of a typo, port $swp1 is configured with a PVID twice (second
command overwrites first), and $swp2 isn't configured at all (and since
the bridge vlan_default_pvid property is set to 0, this port will not
have a PVID at all, so it will drop all untagged and priority-tagged
traffic).
So, instead of testing the configuration that was intended, we are
testing a different one, where one port has PVID 2 and the other has
no PVID. This incorrect version of the test should also pass, but is
ineffective for its purpose, so fix the typo.
This typo has an impact on results of the test results,
potentially leading to wrong conclusions regarding
the functionality of a network device.
Fixes: 476a4f05d9b8 ("selftests: forwarding: add a no_forwarding.sh test")
Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com>
Reviewed-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Kacper Ludwinski <kac.ludwinski(a)icloud.com>
---
tools/testing/selftests/net/forwarding/no_forwarding.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v4:
- Add revision history od this patch
- Add "Reviewed-by:"
- Limit number of characters in commit to 80
- Add impact explanation to commit message
v3:
- Edit commit message
- Add missing Signed-off-by
- Link: https://lore.kernel.org/linux-kselftest/20240927112824.339-1-kac.ludwinski@…
v2:
- Add missing CCs
- Fix typo in commit message
- Add target name
- Link: https://lore.kernel.org/linux-kselftest/fQknN_r6POzmrp8UVjyA3cknLnB1HB9I_jf…
v1:
- Link: https://lore.kernel.org/linux-kselftest/20240925050539.1906-1-kacper@ludwin…
diff --git a/tools/testing/selftests/net/forwarding/no_forwarding.sh b/tools/testing/selftests/net/forwarding/no_forwarding.sh
index 9e677aa64a06..694ece9ba3a7 100755
--- a/tools/testing/selftests/net/forwarding/no_forwarding.sh
+++ b/tools/testing/selftests/net/forwarding/no_forwarding.sh
@@ -202,7 +202,7 @@ one_bridge_two_pvids()
ip link set $swp2 master br0
bridge vlan add dev $swp1 vid 1 pvid untagged
- bridge vlan add dev $swp1 vid 2 pvid untagged
+ bridge vlan add dev $swp2 vid 2 pvid untagged
run_test "Switch ports in VLAN-aware bridge with different PVIDs"
--
2.43.0
Mario brought to my attention that the hugetlb_fault_after_madv test
is currently always skipped on s390x.
Let's adjust the test to be independent of the default hugetlb page size
and while at it, also improve the test output.
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Mario Casquero <mcasquer(a)redhat.com>
Cc: Breno Leitao <leitao(a)debian.org>
David Hildenbrand (2):
selftests/mm: hugetlb_fault_after_madv: use default hguetlb page size
selftests/mm: hugetlb_fault_after_madv: improve test output
.../selftests/mm/hugetlb_fault_after_madv.c | 48 ++++++++++++++++---
1 file changed, 42 insertions(+), 6 deletions(-)
--
2.46.1
Introduce test 'test_proc_pid_mem' to address the issue in the TODO.
Check if VMsize is 0 to determine whether the process has been unmapped.
The child process cannot signal the parent that it has unmapped itself,
as it no longer exists. This includes unmapping the text segment,
preventing the child from proceeding to the next instruction.
Signed-off-by: Siddharth Menon <simeddon(a)gmail.com>
---
v1->v2: Removed redundant parenthesis, fixed other checkpatch warnings.
Revised commit message based on feedback.
tools/testing/selftests/proc/proc-empty-vm.c | 56 +++++++++++++++++---
1 file changed, 50 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/proc/proc-empty-vm.c b/tools/testing/selftests/proc/proc-empty-vm.c
index b3f898aab4ab..bfb7f8823529 100644
--- a/tools/testing/selftests/proc/proc-empty-vm.c
+++ b/tools/testing/selftests/proc/proc-empty-vm.c
@@ -213,6 +213,53 @@ static void vsyscall(void)
}
#endif
+static int test_proc_pid_mem(pid_t pid)
+{
+ char buf[4096];
+ char *line;
+ int vm_size = -1;
+
+ snprintf(buf, sizeof(buf), "/proc/%d/status", pid);
+ int fd = open(buf, O_RDONLY);
+
+ if (fd == -1) {
+ if (errno == ENOENT)
+ /* Process does not exist */
+ return EXIT_SUCCESS;
+
+ perror("open /proc/[pid]/status");
+ return EXIT_FAILURE;
+ }
+
+ ssize_t rv = read(fd, buf, sizeof(buf) - 1);
+
+ if (rv == -1) {
+ perror("read");
+ close(fd);
+ return EXIT_FAILURE;
+ }
+ buf[rv] = '\0';
+
+ line = strtok(buf, "\n");
+ while (line != NULL) {
+ /* Check for VmSize */
+ if (strncmp(line, "VmSize:", 7) == 0) {
+ if (sscanf(line, "VmSize: %d", &vm_size) == 1)
+ break;
+ perror("Failed to parse VmSize.\n");
+ }
+ line = strtok(NULL, "\n");
+ }
+
+ close(fd);
+
+ /* Check if VmSize is 0 */
+ if (vm_size == 0)
+ return EXIT_SUCCESS;
+
+ return EXIT_FAILURE;
+}
+
static int test_proc_pid_maps(pid_t pid)
{
char buf[4096];
@@ -500,14 +547,11 @@ int main(void)
#endif
return EXIT_FAILURE;
} else {
- /*
- * TODO find reliable way to signal parent that munmap(2) completed.
- * Child can't do it directly because it effectively doesn't exist
- * anymore. Looking at child's VM files isn't 100% reliable either:
- * due to a bug they may not become empty or empty-like.
- */
sleep(1);
+ if (rv == EXIT_SUCCESS)
+ rv = test_proc_pid_mem(pid);
+
if (rv == EXIT_SUCCESS) {
rv = test_proc_pid_maps(pid);
}
--
2.39.5