The quilt patch titled
Subject: selftests/mm: add commentary about 9pfs bugs
has been removed from the -mm tree. Its filename was
selftests-mm-add-commentary-about-9pfs-bugs.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Brendan Jackman <jackmanb@xxxxxxxxxx>
Subject: selftests/mm: add commentary about 9pfs bugs
Date: Mon, 17 Mar 2025 10:20:34 +0000
As discussed here:
https://lore.kernel.org/lkml/Z9RRkL1hom48z3Tt@xxxxxxxxxx/
This code could benefit from some more commentary.
To avoid needing to comment the same thing in multiple places (I guess
more of these SKIPs will need to be added over time, for now I am only
like 20% of the way through Project Run run_vmtests.sh Successfully), add
a dummy "skip tests for this specific reason" function that basically just
serves as a hook to hang comments on.
Link: https://lkml.kernel.org/r/20250317-9pfs-comments-v1-1-9ac96043e146@xxxxxxxxxx
Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
Cc: David Hildenbrand <david@xxxxxxxxxx>
Cc: Shuah Khan <shuah@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
tools/testing/selftests/mm/gup_longterm.c | 6 +-----
tools/testing/selftests/mm/map_populate.c | 8 +++-----
tools/testing/selftests/mm/vm_util.h | 18 ++++++++++++++++++
3 files changed, 22 insertions(+), 10 deletions(-)
--- a/tools/testing/selftests/mm/gup_longterm.c~selftests-mm-add-commentary-about-9pfs-bugs
+++ a/tools/testing/selftests/mm/gup_longterm.c
@@ -97,11 +97,7 @@ static void do_test(int fd, size_t size,
if (ftruncate(fd, size)) {
if (errno == ENOENT) {
- /*
- * This can happen if the file has been unlinked and the
- * filesystem doesn't support truncating unlinked files.
- */
- ksft_test_result_skip("ftruncate() failed with ENOENT\n");
+ skip_test_dodgy_fs("ftruncate()");
} else {
ksft_test_result_fail("ftruncate() failed (%s)\n", strerror(errno));
}
--- a/tools/testing/selftests/mm/map_populate.c~selftests-mm-add-commentary-about-9pfs-bugs
+++ a/tools/testing/selftests/mm/map_populate.c
@@ -18,6 +18,8 @@
#include <unistd.h>
#include "../kselftest.h"
+#include "vm_util.h"
+
#define MMAP_SZ 4096
#define BUG_ON(condition, description) \
@@ -88,11 +90,7 @@ int main(int argc, char **argv)
ret = ftruncate(fileno(ftmp), MMAP_SZ);
if (ret < 0 && errno == ENOENT) {
- /*
- * This probably means tmpfile() made a file on a filesystem
- * that doesn't handle temporary files the way we want.
- */
- ksft_exit_skip("ftruncate(fileno(tmpfile())) gave ENOENT, weird filesystem?\n");
+ skip_test_dodgy_fs("ftruncate()");
}
BUG_ON(ret, "ftruncate()");
--- a/tools/testing/selftests/mm/vm_util.h~selftests-mm-add-commentary-about-9pfs-bugs
+++ a/tools/testing/selftests/mm/vm_util.h
@@ -5,6 +5,7 @@
#include <err.h>
#include <strings.h> /* ffsl() */
#include <unistd.h> /* _SC_PAGESIZE */
+#include "../kselftest.h"
#define BIT_ULL(nr) (1ULL << (nr))
#define PM_SOFT_DIRTY BIT_ULL(55)
@@ -32,6 +33,23 @@ static inline unsigned int pshift(void)
return __page_shift;
}
+/*
+ * Plan 9 FS has bugs (at least on QEMU) where certain operations fail with
+ * ENOENT on unlinked files. See
+ * https://gitlab.com/qemu-project/qemu/-/issues/103 for some info about such
+ * bugs. There are rumours of NFS implementations with similar bugs.
+ *
+ * Ideally, tests should just detect filesystems known to have such issues and
+ * bail early. But 9pfs has the additional "feature" that it causes fstatfs to
+ * pass through the f_type field from the host filesystem. To avoid having to
+ * scrape /proc/mounts or some other hackery, tests can call this function when
+ * it seems such a bug might have been encountered.
+ */
+static inline void skip_test_dodgy_fs(const char *op_name)
+{
+ ksft_test_result_skip("%s failed with ENOENT. Filesystem might be buggy (9pfs?)\n", op_name);
+}
+
uint64_t pagemap_get_entry(int fd, char *start);
bool pagemap_is_softdirty(int fd, char *start);
bool pagemap_is_swapped(int fd, char *start);
_
Patches currently in -mm which might be from jackmanb@xxxxxxxxxx are
