arch/m68k/configs/amiga_defconfig | 1 - arch/m68k/configs/apollo_defconfig | 1 - arch/m68k/configs/atari_defconfig | 1 - arch/m68k/configs/bvme6000_defconfig | 1 - arch/m68k/configs/hp300_defconfig | 1 - arch/m68k/configs/mac_defconfig | 1 - arch/m68k/configs/multi_defconfig | 1 - arch/m68k/configs/mvme147_defconfig | 1 - arch/m68k/configs/mvme16x_defconfig | 1 - arch/m68k/configs/q40_defconfig | 1 - arch/m68k/configs/sun3_defconfig | 1 - arch/m68k/configs/sun3x_defconfig | 1 - arch/powerpc/configs/ppc64_defconfig | 1 - lib/Kconfig.debug | 18 +- lib/Makefile | 2 +- lib/test_xarray.c | 669 ++++++++++++++++++++--------------- 16 files changed, 409 insertions(+), 293 deletions(-)
Minimally rewrite the XArray unit tests to use kunit. This integrates
nicely with existing kunit tools which produce nicer human-readable
output compared to the existing machinery.
Running the xarray tests before this change requires an obscure
invocation
```
tools/testing/kunit/kunit.py run --arch arm64 --make_options LLVM=1 \
--kconfig_add CONFIG_TEST_XARRAY=y --raw_output=all nothing
```
which on failure produces
```
BUG at check_reserve:513
...
XArray: 6782340 of 6782364 tests passed
```
and exits 0.
Running the xarray tests after this change requires a simpler invocation
```
tools/testing/kunit/kunit.py run --arch arm64 --make_options LLVM=1 \
xarray
```
which on failure produces (colors omitted)
```
[09:50:53] ====================== check_reserve ======================
[09:50:53] [FAILED] param-0
[09:50:53] # check_reserve: EXPECTATION FAILED at lib/test_xarray.c:536
[09:50:53] xa_erase(xa, 12345678) != NULL
...
[09:50:53] # module: test_xarray
[09:50:53] # xarray: pass:26 fail:3 skip:0 total:29
[09:50:53] # Totals: pass:28 fail:3 skip:0 total:31
[09:50:53] ===================== [FAILED] xarray ======================
```
and exits 1.
Use of richer kunit assertions is intentionally omitted to reduce the
scope of the change.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
---
arch/m68k/configs/amiga_defconfig | 1 -
arch/m68k/configs/apollo_defconfig | 1 -
arch/m68k/configs/atari_defconfig | 1 -
arch/m68k/configs/bvme6000_defconfig | 1 -
arch/m68k/configs/hp300_defconfig | 1 -
arch/m68k/configs/mac_defconfig | 1 -
arch/m68k/configs/multi_defconfig | 1 -
arch/m68k/configs/mvme147_defconfig | 1 -
arch/m68k/configs/mvme16x_defconfig | 1 -
arch/m68k/configs/q40_defconfig | 1 -
arch/m68k/configs/sun3_defconfig | 1 -
arch/m68k/configs/sun3x_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
lib/Kconfig.debug | 18 +-
lib/Makefile | 2 +-
lib/test_xarray.c | 669 ++++++++++++++++++++---------------
16 files changed, 409 insertions(+), 293 deletions(-)
diff --git a/arch/m68k/configs/amiga_defconfig b/arch/m68k/configs/amiga_defconfig
index c705247e7b5b3d67a9e0c2152f479a208d1acd44..581f0080814e92289610463f86abd9b38dab3d3f 100644
--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
@@ -629,7 +629,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/apollo_defconfig b/arch/m68k/configs/apollo_defconfig
index 6d62b9187a58afc079cbefe126d0e2230bbc887c..25628a1e8fa1ccbc8d44398caf4d303fedf50807 100644
--- a/arch/m68k/configs/apollo_defconfig
+++ b/arch/m68k/configs/apollo_defconfig
@@ -586,7 +586,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/atari_defconfig b/arch/m68k/configs/atari_defconfig
index c3c644df852d280139828fce66e55f61eadbeca6..503a9ea526b56ae755b6e74dc02e37177a1a3886 100644
--- a/arch/m68k/configs/atari_defconfig
+++ b/arch/m68k/configs/atari_defconfig
@@ -606,7 +606,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/bvme6000_defconfig b/arch/m68k/configs/bvme6000_defconfig
index 20261f8196918f0315fd29c82c97da0d581a4100..3358349898eff72b250a410940495fb55b597dfa 100644
--- a/arch/m68k/configs/bvme6000_defconfig
+++ b/arch/m68k/configs/bvme6000_defconfig
@@ -578,7 +578,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/hp300_defconfig b/arch/m68k/configs/hp300_defconfig
index ce4fe93a0f701958b5ec79c5d24e9e004e21f076..a5e933a7fdf9dfe16d8943032cf5da062c4c67d0 100644
--- a/arch/m68k/configs/hp300_defconfig
+++ b/arch/m68k/configs/hp300_defconfig
@@ -588,7 +588,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig
index 040ae75f47c3957f2e5c93e19ef397fc23e3dfbd..a90676c04da6d03700a8273b16d22d65630633a7 100644
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -605,7 +605,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/multi_defconfig b/arch/m68k/configs/multi_defconfig
index 20d877cb4e308b10e48bfd872c45af795feed098..f28f7783b090e79ed6840df8e052fe43308d1302 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -692,7 +692,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/mvme147_defconfig b/arch/m68k/configs/mvme147_defconfig
index 5e1c8d0d3da57de9397220b9544e0f883c4c2c30..61308c2cd96cfbf035b47ca7ac3d9366c61e1740 100644
--- a/arch/m68k/configs/mvme147_defconfig
+++ b/arch/m68k/configs/mvme147_defconfig
@@ -578,7 +578,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/mvme16x_defconfig b/arch/m68k/configs/mvme16x_defconfig
index 5d1409e6a13773b43236ebe6d9a442348ac624a6..9ec8eb9ea6147c22dbeba8c90ea211404ed2dfc8 100644
--- a/arch/m68k/configs/mvme16x_defconfig
+++ b/arch/m68k/configs/mvme16x_defconfig
@@ -579,7 +579,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/q40_defconfig b/arch/m68k/configs/q40_defconfig
index e4c30e2b9bbb8753a2fec9422ab5770ecd38d8bc..5fd094391b9ecf3a7dd73f49432f8e64856f1887 100644
--- a/arch/m68k/configs/q40_defconfig
+++ b/arch/m68k/configs/q40_defconfig
@@ -595,7 +595,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/sun3_defconfig b/arch/m68k/configs/sun3_defconfig
index 980843a9ea1eeda6d1d692e5772d5ad62adbeeec..5e9c9d704c2ee8df7e9fe1d73fcaef3f0ae2aa37 100644
--- a/arch/m68k/configs/sun3_defconfig
+++ b/arch/m68k/configs/sun3_defconfig
@@ -575,7 +575,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/m68k/configs/sun3x_defconfig b/arch/m68k/configs/sun3x_defconfig
index 38681cc6b598c5b433f04998d9af58ec6c2c58f2..b2f5f398fe42ae150049424e26f988cffa33062f 100644
--- a/arch/m68k/configs/sun3x_defconfig
+++ b/arch/m68k/configs/sun3x_defconfig
@@ -576,7 +576,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index f39c0d000c4386dc77fe36965e38a96f5f11daac..bc48063fd860627fdf24ee8dbe18cdedcec79078 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -451,7 +451,6 @@ CONFIG_TEST_PRINTF=m
CONFIG_TEST_SCANF=m
CONFIG_TEST_BITMAP=m
CONFIG_TEST_UUID=m
-CONFIG_TEST_XARRAY=m
CONFIG_TEST_MAPLE_TREE=m
CONFIG_TEST_RHASHTABLE=m
CONFIG_TEST_IDA=m
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e968f083d356a53a87aa73d08caeb8471ea3603a..b53f5da22e4053dee79860c9a10d8dd26a7080d6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2456,8 +2456,22 @@ config TEST_BITMAP
config TEST_UUID
tristate "Test functions located in the uuid module at runtime"
-config TEST_XARRAY
- tristate "Test the XArray code at runtime"
+config XARRAY_KUNIT
+ tristate "KUnit test XArray code at runtime" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ Enable this option to test the Xarray code at boot.
+
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
config TEST_MAPLE_TREE
tristate "Test the Maple Tree code at runtime or module load"
diff --git a/lib/Makefile b/lib/Makefile
index a8155c972f02856fcc61ee949ddda436cfe211ff..c0458ff841fe8feff840c77bb652adb2aae48678 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -94,7 +94,6 @@ GCOV_PROFILE_test_bitmap.o := n
endif
obj-$(CONFIG_TEST_UUID) += test_uuid.o
-obj-$(CONFIG_TEST_XARRAY) += test_xarray.o
obj-$(CONFIG_TEST_MAPLE_TREE) += test_maple_tree.o
obj-$(CONFIG_TEST_PARMAN) += test_parman.o
obj-$(CONFIG_TEST_KMOD) += test_kmod.o
@@ -375,6 +374,7 @@ CFLAGS_bitfield_kunit.o := $(DISABLE_STRUCTLEAK_PLUGIN)
obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
obj-$(CONFIG_CHECKSUM_KUNIT) += checksum_kunit.o
obj-$(CONFIG_UTIL_MACROS_KUNIT) += util_macros_kunit.o
+obj-$(CONFIG_XARRAY_KUNIT) += test_xarray.o
obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
obj-$(CONFIG_HASHTABLE_KUNIT_TEST) += hashtable_test.o
obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
diff --git a/lib/test_xarray.c b/lib/test_xarray.c
index d5c5cbba33edf30104e9bed40ec4298638e7a9e5..9d0e797b825fe308ffa3b68904e708e32d9b7857 100644
--- a/lib/test_xarray.c
+++ b/lib/test_xarray.c
@@ -6,11 +6,10 @@
* Author: Matthew Wilcox <willy@infradead.org>
*/
-#include <linux/xarray.h>
-#include <linux/module.h>
+#include <kunit/test.h>
-static unsigned int tests_run;
-static unsigned int tests_passed;
+#include <linux/module.h>
+#include <linux/xarray.h>
static const unsigned int order_limit =
IS_ENABLED(CONFIG_XARRAY_MULTI) ? BITS_PER_LONG : 1;
@@ -20,15 +19,12 @@ static const unsigned int order_limit =
void xa_dump(const struct xarray *xa) { }
# endif
#undef XA_BUG_ON
-#define XA_BUG_ON(xa, x) do { \
- tests_run++; \
- if (x) { \
- printk("BUG at %s:%d\n", __func__, __LINE__); \
- xa_dump(xa); \
- dump_stack(); \
- } else { \
- tests_passed++; \
- } \
+#define XA_BUG_ON(xa, x) do { \
+ if (x) { \
+ KUNIT_FAIL(test, #x); \
+ xa_dump(xa); \
+ dump_stack(); \
+ } \
} while (0)
#endif
@@ -42,13 +38,13 @@ static void *xa_store_index(struct xarray *xa, unsigned long index, gfp_t gfp)
return xa_store(xa, index, xa_mk_index(index), gfp);
}
-static void xa_insert_index(struct xarray *xa, unsigned long index)
+static void xa_insert_index(struct kunit *test, struct xarray *xa, unsigned long index)
{
XA_BUG_ON(xa, xa_insert(xa, index, xa_mk_index(index),
GFP_KERNEL) != 0);
}
-static void xa_alloc_index(struct xarray *xa, unsigned long index, gfp_t gfp)
+static void xa_alloc_index(struct kunit *test, struct xarray *xa, unsigned long index, gfp_t gfp)
{
u32 id;
@@ -57,7 +53,7 @@ static void xa_alloc_index(struct xarray *xa, unsigned long index, gfp_t gfp)
XA_BUG_ON(xa, id != index);
}
-static void xa_erase_index(struct xarray *xa, unsigned long index)
+static void xa_erase_index(struct kunit *test, struct xarray *xa, unsigned long index)
{
XA_BUG_ON(xa, xa_erase(xa, index) != xa_mk_index(index));
XA_BUG_ON(xa, xa_load(xa, index) != NULL);
@@ -83,8 +79,15 @@ static void *xa_store_order(struct xarray *xa, unsigned long index,
return curr;
}
-static noinline void check_xa_err(struct xarray *xa)
+static inline struct xarray *xa_param(struct kunit *test)
{
+ return *(struct xarray **)test->param_value;
+}
+
+static noinline void check_xa_err(struct kunit *test)
+{
+ struct xarray *xa = xa_param(test);
+
XA_BUG_ON(xa, xa_err(xa_store_index(xa, 0, GFP_NOWAIT)) != 0);
XA_BUG_ON(xa, xa_err(xa_erase(xa, 0)) != 0);
#ifndef __KERNEL__
@@ -99,8 +102,10 @@ static noinline void check_xa_err(struct xarray *xa)
// XA_BUG_ON(xa, xa_err(xa_store(xa, 0, xa_mk_internal(0), 0)) != -EINVAL);
}
-static noinline void check_xas_retry(struct xarray *xa)
+static noinline void check_xas_retry(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
void *entry;
@@ -109,7 +114,7 @@ static noinline void check_xas_retry(struct xarray *xa)
rcu_read_lock();
XA_BUG_ON(xa, xas_find(&xas, ULONG_MAX) != xa_mk_value(0));
- xa_erase_index(xa, 1);
+ xa_erase_index(test, xa, 1);
XA_BUG_ON(xa, !xa_is_retry(xas_reload(&xas)));
XA_BUG_ON(xa, xas_retry(&xas, NULL));
XA_BUG_ON(xa, xas_retry(&xas, xa_mk_value(0)));
@@ -140,12 +145,14 @@ static noinline void check_xas_retry(struct xarray *xa)
}
xas_unlock(&xas);
- xa_erase_index(xa, 0);
- xa_erase_index(xa, 1);
+ xa_erase_index(test, xa, 0);
+ xa_erase_index(test, xa, 1);
}
-static noinline void check_xa_load(struct xarray *xa)
+static noinline void check_xa_load(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long i, j;
for (i = 0; i < 1024; i++) {
@@ -167,13 +174,15 @@ static noinline void check_xa_load(struct xarray *xa)
else
XA_BUG_ON(xa, entry);
}
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
}
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_xa_mark_1(struct xarray *xa, unsigned long index)
+static noinline void check_xa_mark_1(struct kunit *test, unsigned long index)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int order;
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 8 : 1;
@@ -193,7 +202,7 @@ static noinline void check_xa_mark_1(struct xarray *xa, unsigned long index)
XA_BUG_ON(xa, xa_get_mark(xa, index, XA_MARK_1));
/* Storing NULL clears marks, and they can't be set again */
- xa_erase_index(xa, index);
+ xa_erase_index(test, xa, index);
XA_BUG_ON(xa, !xa_empty(xa));
XA_BUG_ON(xa, xa_get_mark(xa, index, XA_MARK_0));
xa_set_mark(xa, index, XA_MARK_0);
@@ -244,15 +253,17 @@ static noinline void check_xa_mark_1(struct xarray *xa, unsigned long index)
XA_BUG_ON(xa, xa_get_mark(xa, next, XA_MARK_0));
XA_BUG_ON(xa, xa_get_mark(xa, next, XA_MARK_1));
XA_BUG_ON(xa, xa_get_mark(xa, next, XA_MARK_2));
- xa_erase_index(xa, index);
- xa_erase_index(xa, next);
+ xa_erase_index(test, xa, index);
+ xa_erase_index(test, xa, next);
XA_BUG_ON(xa, !xa_empty(xa));
}
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_xa_mark_2(struct xarray *xa)
+static noinline void check_xa_mark_2(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
unsigned long index;
unsigned int count = 0;
@@ -289,9 +300,11 @@ static noinline void check_xa_mark_2(struct xarray *xa)
xa_destroy(xa);
}
-static noinline void check_xa_mark_3(struct xarray *xa)
+static noinline void check_xa_mark_3(struct kunit *test)
{
#ifdef CONFIG_XARRAY_MULTI
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0x41);
void *entry;
int count = 0;
@@ -310,19 +323,21 @@ static noinline void check_xa_mark_3(struct xarray *xa)
#endif
}
-static noinline void check_xa_mark(struct xarray *xa)
+static noinline void check_xa_mark(struct kunit *test)
{
unsigned long index;
for (index = 0; index < 16384; index += 4)
- check_xa_mark_1(xa, index);
+ check_xa_mark_1(test, index);
- check_xa_mark_2(xa);
- check_xa_mark_3(xa);
+ check_xa_mark_2(test);
+ check_xa_mark_3(test);
}
-static noinline void check_xa_shrink(struct xarray *xa)
+static noinline void check_xa_shrink(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 1);
struct xa_node *node;
unsigned int order;
@@ -347,7 +362,7 @@ static noinline void check_xa_shrink(struct xarray *xa)
XA_BUG_ON(xa, xas_load(&xas) != NULL);
xas_unlock(&xas);
XA_BUG_ON(xa, xa_load(xa, 0) != xa_mk_value(0));
- xa_erase_index(xa, 0);
+ xa_erase_index(test, xa, 0);
XA_BUG_ON(xa, !xa_empty(xa));
for (order = 0; order < max_order; order++) {
@@ -364,45 +379,49 @@ static noinline void check_xa_shrink(struct xarray *xa)
XA_BUG_ON(xa, xa_head(xa) == node);
rcu_read_unlock();
XA_BUG_ON(xa, xa_load(xa, max + 1) != NULL);
- xa_erase_index(xa, ULONG_MAX);
+ xa_erase_index(test, xa, ULONG_MAX);
XA_BUG_ON(xa, xa->xa_head != node);
- xa_erase_index(xa, 0);
+ xa_erase_index(test, xa, 0);
}
}
-static noinline void check_insert(struct xarray *xa)
+static noinline void check_insert(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long i;
for (i = 0; i < 1024; i++) {
- xa_insert_index(xa, i);
+ xa_insert_index(test, xa, i);
XA_BUG_ON(xa, xa_load(xa, i - 1) != NULL);
XA_BUG_ON(xa, xa_load(xa, i + 1) != NULL);
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
}
for (i = 10; i < BITS_PER_LONG; i++) {
- xa_insert_index(xa, 1UL << i);
+ xa_insert_index(test, xa, 1UL << i);
XA_BUG_ON(xa, xa_load(xa, (1UL << i) - 1) != NULL);
XA_BUG_ON(xa, xa_load(xa, (1UL << i) + 1) != NULL);
- xa_erase_index(xa, 1UL << i);
+ xa_erase_index(test, xa, 1UL << i);
- xa_insert_index(xa, (1UL << i) - 1);
+ xa_insert_index(test, xa, (1UL << i) - 1);
XA_BUG_ON(xa, xa_load(xa, (1UL << i) - 2) != NULL);
XA_BUG_ON(xa, xa_load(xa, 1UL << i) != NULL);
- xa_erase_index(xa, (1UL << i) - 1);
+ xa_erase_index(test, xa, (1UL << i) - 1);
}
- xa_insert_index(xa, ~0UL);
+ xa_insert_index(test, xa, ~0UL);
XA_BUG_ON(xa, xa_load(xa, 0UL) != NULL);
XA_BUG_ON(xa, xa_load(xa, ~1UL) != NULL);
- xa_erase_index(xa, ~0UL);
+ xa_erase_index(test, xa, ~0UL);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_cmpxchg(struct xarray *xa)
+static noinline void check_cmpxchg(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
void *FIVE = xa_mk_value(5);
void *SIX = xa_mk_value(6);
void *LOTS = xa_mk_value(12345678);
@@ -418,14 +437,16 @@ static noinline void check_cmpxchg(struct xarray *xa)
XA_BUG_ON(xa, xa_insert(xa, 5, FIVE, GFP_KERNEL) != -EBUSY);
XA_BUG_ON(xa, xa_cmpxchg(xa, 5, FIVE, NULL, GFP_KERNEL) != FIVE);
XA_BUG_ON(xa, xa_insert(xa, 5, FIVE, GFP_KERNEL) == -EBUSY);
- xa_erase_index(xa, 12345678);
- xa_erase_index(xa, 5);
+ xa_erase_index(test, xa, 12345678);
+ xa_erase_index(test, xa, 5);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_cmpxchg_order(struct xarray *xa)
+static noinline void check_cmpxchg_order(struct kunit *test)
{
#ifdef CONFIG_XARRAY_MULTI
+ struct xarray *xa = xa_param(test);
+
void *FIVE = xa_mk_value(5);
unsigned int i, order = 3;
@@ -476,8 +497,10 @@ static noinline void check_cmpxchg_order(struct xarray *xa)
#endif
}
-static noinline void check_reserve(struct xarray *xa)
+static noinline void check_reserve(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
void *entry;
unsigned long index;
int count;
@@ -494,7 +517,7 @@ static noinline void check_reserve(struct xarray *xa)
XA_BUG_ON(xa, xa_reserve(xa, 12345678, GFP_KERNEL) != 0);
XA_BUG_ON(xa, xa_store_index(xa, 12345678, GFP_NOWAIT) != NULL);
xa_release(xa, 12345678);
- xa_erase_index(xa, 12345678);
+ xa_erase_index(test, xa, 12345678);
XA_BUG_ON(xa, !xa_empty(xa));
/* cmpxchg sees a reserved entry as ZERO */
@@ -502,7 +525,7 @@ static noinline void check_reserve(struct xarray *xa)
XA_BUG_ON(xa, xa_cmpxchg(xa, 12345678, XA_ZERO_ENTRY,
xa_mk_value(12345678), GFP_NOWAIT) != NULL);
xa_release(xa, 12345678);
- xa_erase_index(xa, 12345678);
+ xa_erase_index(test, xa, 12345678);
XA_BUG_ON(xa, !xa_empty(xa));
/* xa_insert treats it as busy */
@@ -542,8 +565,10 @@ static noinline void check_reserve(struct xarray *xa)
xa_destroy(xa);
}
-static noinline void check_xas_erase(struct xarray *xa)
+static noinline void check_xas_erase(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
void *entry;
unsigned long i, j;
@@ -581,9 +606,11 @@ static noinline void check_xas_erase(struct xarray *xa)
}
#ifdef CONFIG_XARRAY_MULTI
-static noinline void check_multi_store_1(struct xarray *xa, unsigned long index,
+static noinline void check_multi_store_1(struct kunit *test, unsigned long index,
unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, index);
unsigned long min = index & ~((1UL << order) - 1);
unsigned long max = min + (1UL << order);
@@ -602,13 +629,15 @@ static noinline void check_multi_store_1(struct xarray *xa, unsigned long index,
XA_BUG_ON(xa, xa_load(xa, max) != NULL);
XA_BUG_ON(xa, xa_load(xa, min - 1) != NULL);
- xa_erase_index(xa, min);
+ xa_erase_index(test, xa, min);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_multi_store_2(struct xarray *xa, unsigned long index,
+static noinline void check_multi_store_2(struct kunit *test, unsigned long index,
unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, index);
xa_store_order(xa, index, order, xa_mk_value(0), GFP_KERNEL);
@@ -620,9 +649,11 @@ static noinline void check_multi_store_2(struct xarray *xa, unsigned long index,
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_multi_store_3(struct xarray *xa, unsigned long index,
+static noinline void check_multi_store_3(struct kunit *test, unsigned long index,
unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
void *entry;
int n = 0;
@@ -647,9 +678,11 @@ static noinline void check_multi_store_3(struct xarray *xa, unsigned long index,
}
#endif
-static noinline void check_multi_store(struct xarray *xa)
+static noinline void check_multi_store(struct kunit *test)
{
#ifdef CONFIG_XARRAY_MULTI
+ struct xarray *xa = xa_param(test);
+
unsigned long i, j, k;
unsigned int max_order = (sizeof(long) == 4) ? 30 : 60;
@@ -714,26 +747,28 @@ static noinline void check_multi_store(struct xarray *xa)
}
for (i = 0; i < 20; i++) {
- check_multi_store_1(xa, 200, i);
- check_multi_store_1(xa, 0, i);
- check_multi_store_1(xa, (1UL << i) + 1, i);
+ check_multi_store_1(test, 200, i);
+ check_multi_store_1(test, 0, i);
+ check_multi_store_1(test, (1UL << i) + 1, i);
}
- check_multi_store_2(xa, 4095, 9);
+ check_multi_store_2(test, 4095, 9);
for (i = 1; i < 20; i++) {
- check_multi_store_3(xa, 0, i);
- check_multi_store_3(xa, 1UL << i, i);
+ check_multi_store_3(test, 0, i);
+ check_multi_store_3(test, 1UL << i, i);
}
#endif
}
#ifdef CONFIG_XARRAY_MULTI
/* mimics page cache __filemap_add_folio() */
-static noinline void check_xa_multi_store_adv_add(struct xarray *xa,
+static noinline void check_xa_multi_store_adv_add(struct kunit *test,
unsigned long index,
unsigned int order,
void *p)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, index);
unsigned int nrpages = 1UL << order;
@@ -761,10 +796,12 @@ static noinline void check_xa_multi_store_adv_add(struct xarray *xa,
}
/* mimics page_cache_delete() */
-static noinline void check_xa_multi_store_adv_del_entry(struct xarray *xa,
+static noinline void check_xa_multi_store_adv_del_entry(struct kunit *test,
unsigned long index,
unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, index);
xas_set_order(&xas, index, order);
@@ -772,12 +809,14 @@ static noinline void check_xa_multi_store_adv_del_entry(struct xarray *xa,
xas_init_marks(&xas);
}
-static noinline void check_xa_multi_store_adv_delete(struct xarray *xa,
+static noinline void check_xa_multi_store_adv_delete(struct kunit *test,
unsigned long index,
unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
xa_lock_irq(xa);
- check_xa_multi_store_adv_del_entry(xa, index, order);
+ check_xa_multi_store_adv_del_entry(test, index, order);
xa_unlock_irq(xa);
}
@@ -814,10 +853,12 @@ static unsigned long some_val = 0xdeadbeef;
static unsigned long some_val_2 = 0xdeaddead;
/* mimics the page cache usage */
-static noinline void check_xa_multi_store_adv(struct xarray *xa,
+static noinline void check_xa_multi_store_adv(struct kunit *test,
unsigned long pos,
unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int nrpages = 1UL << order;
unsigned long index, base, next_index, next_next_index;
unsigned int i;
@@ -827,7 +868,7 @@ static noinline void check_xa_multi_store_adv(struct xarray *xa,
next_index = round_down(base + nrpages, nrpages);
next_next_index = round_down(next_index + nrpages, nrpages);
- check_xa_multi_store_adv_add(xa, base, order, &some_val);
+ check_xa_multi_store_adv_add(test, base, order, &some_val);
for (i = 0; i < nrpages; i++)
XA_BUG_ON(xa, test_get_entry(xa, base + i) != &some_val);
@@ -835,20 +876,20 @@ static noinline void check_xa_multi_store_adv(struct xarray *xa,
XA_BUG_ON(xa, test_get_entry(xa, next_index) != NULL);
/* Use order 0 for the next item */
- check_xa_multi_store_adv_add(xa, next_index, 0, &some_val_2);
+ check_xa_multi_store_adv_add(test, next_index, 0, &some_val_2);
XA_BUG_ON(xa, test_get_entry(xa, next_index) != &some_val_2);
/* Remove the next item */
- check_xa_multi_store_adv_delete(xa, next_index, 0);
+ check_xa_multi_store_adv_delete(test, next_index, 0);
/* Now use order for a new pointer */
- check_xa_multi_store_adv_add(xa, next_index, order, &some_val_2);
+ check_xa_multi_store_adv_add(test, next_index, order, &some_val_2);
for (i = 0; i < nrpages; i++)
XA_BUG_ON(xa, test_get_entry(xa, next_index + i) != &some_val_2);
- check_xa_multi_store_adv_delete(xa, next_index, order);
- check_xa_multi_store_adv_delete(xa, base, order);
+ check_xa_multi_store_adv_delete(test, next_index, order);
+ check_xa_multi_store_adv_delete(test, base, order);
XA_BUG_ON(xa, !xa_empty(xa));
/* starting fresh again */
@@ -856,7 +897,7 @@ static noinline void check_xa_multi_store_adv(struct xarray *xa,
/* let's test some holes now */
/* hole at base and next_next */
- check_xa_multi_store_adv_add(xa, next_index, order, &some_val_2);
+ check_xa_multi_store_adv_add(test, next_index, order, &some_val_2);
for (i = 0; i < nrpages; i++)
XA_BUG_ON(xa, test_get_entry(xa, base + i) != NULL);
@@ -867,12 +908,12 @@ static noinline void check_xa_multi_store_adv(struct xarray *xa,
for (i = 0; i < nrpages; i++)
XA_BUG_ON(xa, test_get_entry(xa, next_next_index + i) != NULL);
- check_xa_multi_store_adv_delete(xa, next_index, order);
+ check_xa_multi_store_adv_delete(test, next_index, order);
XA_BUG_ON(xa, !xa_empty(xa));
/* hole at base and next */
- check_xa_multi_store_adv_add(xa, next_next_index, order, &some_val_2);
+ check_xa_multi_store_adv_add(test, next_next_index, order, &some_val_2);
for (i = 0; i < nrpages; i++)
XA_BUG_ON(xa, test_get_entry(xa, base + i) != NULL);
@@ -883,12 +924,12 @@ static noinline void check_xa_multi_store_adv(struct xarray *xa,
for (i = 0; i < nrpages; i++)
XA_BUG_ON(xa, test_get_entry(xa, next_next_index + i) != &some_val_2);
- check_xa_multi_store_adv_delete(xa, next_next_index, order);
+ check_xa_multi_store_adv_delete(test, next_next_index, order);
XA_BUG_ON(xa, !xa_empty(xa));
}
#endif
-static noinline void check_multi_store_advanced(struct xarray *xa)
+static noinline void check_multi_store_advanced(struct kunit *test)
{
#ifdef CONFIG_XARRAY_MULTI
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 20 : 1;
@@ -900,59 +941,59 @@ static noinline void check_multi_store_advanced(struct xarray *xa)
*/
for (pos = 7; pos < end; pos = (pos * pos) + 564) {
for (i = 0; i < max_order; i++) {
- check_xa_multi_store_adv(xa, pos, i);
- check_xa_multi_store_adv(xa, pos + 157, i);
+ check_xa_multi_store_adv(test, pos, i);
+ check_xa_multi_store_adv(test, pos + 157, i);
}
}
#endif
}
-static noinline void check_xa_alloc_1(struct xarray *xa, unsigned int base)
+static noinline void check_xa_alloc_1(struct kunit *test, struct xarray *xa, unsigned int base)
{
int i;
u32 id;
XA_BUG_ON(xa, !xa_empty(xa));
/* An empty array should assign %base to the first alloc */
- xa_alloc_index(xa, base, GFP_KERNEL);
+ xa_alloc_index(test, xa, base, GFP_KERNEL);
/* Erasing it should make the array empty again */
- xa_erase_index(xa, base);
+ xa_erase_index(test, xa, base);
XA_BUG_ON(xa, !xa_empty(xa));
/* And it should assign %base again */
- xa_alloc_index(xa, base, GFP_KERNEL);
+ xa_alloc_index(test, xa, base, GFP_KERNEL);
/* Allocating and then erasing a lot should not lose base */
for (i = base + 1; i < 2 * XA_CHUNK_SIZE; i++)
- xa_alloc_index(xa, i, GFP_KERNEL);
+ xa_alloc_index(test, xa, i, GFP_KERNEL);
for (i = base; i < 2 * XA_CHUNK_SIZE; i++)
- xa_erase_index(xa, i);
- xa_alloc_index(xa, base, GFP_KERNEL);
+ xa_erase_index(test, xa, i);
+ xa_alloc_index(test, xa, base, GFP_KERNEL);
/* Destroying the array should do the same as erasing */
xa_destroy(xa);
/* And it should assign %base again */
- xa_alloc_index(xa, base, GFP_KERNEL);
+ xa_alloc_index(test, xa, base, GFP_KERNEL);
/* The next assigned ID should be base+1 */
- xa_alloc_index(xa, base + 1, GFP_KERNEL);
- xa_erase_index(xa, base + 1);
+ xa_alloc_index(test, xa, base + 1, GFP_KERNEL);
+ xa_erase_index(test, xa, base + 1);
/* Storing a value should mark it used */
xa_store_index(xa, base + 1, GFP_KERNEL);
- xa_alloc_index(xa, base + 2, GFP_KERNEL);
+ xa_alloc_index(test, xa, base + 2, GFP_KERNEL);
/* If we then erase base, it should be free */
- xa_erase_index(xa, base);
- xa_alloc_index(xa, base, GFP_KERNEL);
+ xa_erase_index(test, xa, base);
+ xa_alloc_index(test, xa, base, GFP_KERNEL);
- xa_erase_index(xa, base + 1);
- xa_erase_index(xa, base + 2);
+ xa_erase_index(test, xa, base + 1);
+ xa_erase_index(test, xa, base + 2);
for (i = 1; i < 5000; i++) {
- xa_alloc_index(xa, base + i, GFP_KERNEL);
+ xa_alloc_index(test, xa, base + i, GFP_KERNEL);
}
xa_destroy(xa);
@@ -978,11 +1019,11 @@ static noinline void check_xa_alloc_1(struct xarray *xa, unsigned int base)
XA_BUG_ON(xa, xa_store_index(xa, 3, GFP_KERNEL) != 0);
XA_BUG_ON(xa, xa_alloc(xa, &id, xa_mk_index(10), XA_LIMIT(10, 5),
GFP_KERNEL) != -EBUSY);
- xa_erase_index(xa, 3);
+ xa_erase_index(test, xa, 3);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_xa_alloc_2(struct xarray *xa, unsigned int base)
+static noinline void check_xa_alloc_2(struct kunit *test, struct xarray *xa, unsigned int base)
{
unsigned int i, id;
unsigned long index;
@@ -1018,7 +1059,7 @@ static noinline void check_xa_alloc_2(struct xarray *xa, unsigned int base)
XA_BUG_ON(xa, id != 5);
xa_for_each(xa, index, entry) {
- xa_erase_index(xa, index);
+ xa_erase_index(test, xa, index);
}
for (i = base; i < base + 9; i++) {
@@ -1033,7 +1074,7 @@ static noinline void check_xa_alloc_2(struct xarray *xa, unsigned int base)
xa_destroy(xa);
}
-static noinline void check_xa_alloc_3(struct xarray *xa, unsigned int base)
+static noinline void check_xa_alloc_3(struct kunit *test, struct xarray *xa, unsigned int base)
{
struct xa_limit limit = XA_LIMIT(1, 0x3fff);
u32 next = 0;
@@ -1049,8 +1090,8 @@ static noinline void check_xa_alloc_3(struct xarray *xa, unsigned int base)
XA_BUG_ON(xa, xa_alloc_cyclic(xa, &id, xa_mk_index(0x3ffd), limit,
&next, GFP_KERNEL) != 0);
XA_BUG_ON(xa, id != 0x3ffd);
- xa_erase_index(xa, 0x3ffd);
- xa_erase_index(xa, 1);
+ xa_erase_index(test, xa, 0x3ffd);
+ xa_erase_index(test, xa, 1);
XA_BUG_ON(xa, !xa_empty(xa));
for (i = 0x3ffe; i < 0x4003; i++) {
@@ -1065,8 +1106,8 @@ static noinline void check_xa_alloc_3(struct xarray *xa, unsigned int base)
/* Check wrap-around is handled correctly */
if (base != 0)
- xa_erase_index(xa, base);
- xa_erase_index(xa, base + 1);
+ xa_erase_index(test, xa, base);
+ xa_erase_index(test, xa, base + 1);
next = UINT_MAX;
XA_BUG_ON(xa, xa_alloc_cyclic(xa, &id, xa_mk_index(UINT_MAX),
xa_limit_32b, &next, GFP_KERNEL) != 0);
@@ -1079,7 +1120,7 @@ static noinline void check_xa_alloc_3(struct xarray *xa, unsigned int base)
XA_BUG_ON(xa, id != base + 1);
xa_for_each(xa, index, entry)
- xa_erase_index(xa, index);
+ xa_erase_index(test, xa, index);
XA_BUG_ON(xa, !xa_empty(xa));
}
@@ -1087,19 +1128,21 @@ static noinline void check_xa_alloc_3(struct xarray *xa, unsigned int base)
static DEFINE_XARRAY_ALLOC(xa0);
static DEFINE_XARRAY_ALLOC1(xa1);
-static noinline void check_xa_alloc(void)
+static noinline void check_xa_alloc(struct kunit *test)
{
- check_xa_alloc_1(&xa0, 0);
- check_xa_alloc_1(&xa1, 1);
- check_xa_alloc_2(&xa0, 0);
- check_xa_alloc_2(&xa1, 1);
- check_xa_alloc_3(&xa0, 0);
- check_xa_alloc_3(&xa1, 1);
+ check_xa_alloc_1(test, &xa0, 0);
+ check_xa_alloc_1(test, &xa1, 1);
+ check_xa_alloc_2(test, &xa0, 0);
+ check_xa_alloc_2(test, &xa1, 1);
+ check_xa_alloc_3(test, &xa0, 0);
+ check_xa_alloc_3(test, &xa1, 1);
}
-static noinline void __check_store_iter(struct xarray *xa, unsigned long start,
+static noinline void __check_store_iter(struct kunit *test, unsigned long start,
unsigned int order, unsigned int present)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE_ORDER(xas, xa, start, order);
void *entry;
unsigned int count = 0;
@@ -1123,50 +1166,54 @@ static noinline void __check_store_iter(struct xarray *xa, unsigned long start,
XA_BUG_ON(xa, xa_load(xa, start) != xa_mk_index(start));
XA_BUG_ON(xa, xa_load(xa, start + (1UL << order) - 1) !=
xa_mk_index(start));
- xa_erase_index(xa, start);
+ xa_erase_index(test, xa, start);
}
-static noinline void check_store_iter(struct xarray *xa)
+static noinline void check_store_iter(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int i, j;
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 20 : 1;
for (i = 0; i < max_order; i++) {
unsigned int min = 1 << i;
unsigned int max = (2 << i) - 1;
- __check_store_iter(xa, 0, i, 0);
+ __check_store_iter(test, 0, i, 0);
XA_BUG_ON(xa, !xa_empty(xa));
- __check_store_iter(xa, min, i, 0);
+ __check_store_iter(test, min, i, 0);
XA_BUG_ON(xa, !xa_empty(xa));
xa_store_index(xa, min, GFP_KERNEL);
- __check_store_iter(xa, min, i, 1);
+ __check_store_iter(test, min, i, 1);
XA_BUG_ON(xa, !xa_empty(xa));
xa_store_index(xa, max, GFP_KERNEL);
- __check_store_iter(xa, min, i, 1);
+ __check_store_iter(test, min, i, 1);
XA_BUG_ON(xa, !xa_empty(xa));
for (j = 0; j < min; j++)
xa_store_index(xa, j, GFP_KERNEL);
- __check_store_iter(xa, 0, i, min);
+ __check_store_iter(test, 0, i, min);
XA_BUG_ON(xa, !xa_empty(xa));
for (j = 0; j < min; j++)
xa_store_index(xa, min + j, GFP_KERNEL);
- __check_store_iter(xa, min, i, min);
+ __check_store_iter(test, min, i, min);
XA_BUG_ON(xa, !xa_empty(xa));
}
#ifdef CONFIG_XARRAY_MULTI
xa_store_index(xa, 63, GFP_KERNEL);
xa_store_index(xa, 65, GFP_KERNEL);
- __check_store_iter(xa, 64, 2, 1);
- xa_erase_index(xa, 63);
+ __check_store_iter(test, 64, 2, 1);
+ xa_erase_index(test, xa, 63);
#endif
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_multi_find_1(struct xarray *xa, unsigned order)
+static noinline void check_multi_find_1(struct kunit *test, unsigned int order)
{
#ifdef CONFIG_XARRAY_MULTI
+ struct xarray *xa = xa_param(test);
+
unsigned long multi = 3 << order;
unsigned long next = 4 << order;
unsigned long index;
@@ -1189,15 +1236,17 @@ static noinline void check_multi_find_1(struct xarray *xa, unsigned order)
XA_BUG_ON(xa, xa_find_after(xa, &index, next, XA_PRESENT) != NULL);
XA_BUG_ON(xa, index != next);
- xa_erase_index(xa, multi);
- xa_erase_index(xa, next);
- xa_erase_index(xa, next + 1);
+ xa_erase_index(test, xa, multi);
+ xa_erase_index(test, xa, next);
+ xa_erase_index(test, xa, next + 1);
XA_BUG_ON(xa, !xa_empty(xa));
#endif
}
-static noinline void check_multi_find_2(struct xarray *xa)
+static noinline void check_multi_find_2(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 10 : 1;
unsigned int i, j;
void *entry;
@@ -1211,17 +1260,19 @@ static noinline void check_multi_find_2(struct xarray *xa)
GFP_KERNEL);
rcu_read_lock();
xas_for_each(&xas, entry, ULONG_MAX) {
- xa_erase_index(xa, index);
+ xa_erase_index(test, xa, index);
}
rcu_read_unlock();
- xa_erase_index(xa, index - 1);
+ xa_erase_index(test, xa, index - 1);
XA_BUG_ON(xa, !xa_empty(xa));
}
}
}
-static noinline void check_multi_find_3(struct xarray *xa)
+static noinline void check_multi_find_3(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int order;
for (order = 5; order < order_limit; order++) {
@@ -1230,12 +1281,14 @@ static noinline void check_multi_find_3(struct xarray *xa)
XA_BUG_ON(xa, !xa_empty(xa));
xa_store_order(xa, 0, order - 4, xa_mk_index(0), GFP_KERNEL);
XA_BUG_ON(xa, xa_find_after(xa, &index, ULONG_MAX, XA_PRESENT));
- xa_erase_index(xa, 0);
+ xa_erase_index(test, xa, 0);
}
}
-static noinline void check_find_1(struct xarray *xa)
+static noinline void check_find_1(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long i, j, k;
XA_BUG_ON(xa, !xa_empty(xa));
@@ -1272,18 +1325,20 @@ static noinline void check_find_1(struct xarray *xa)
else
XA_BUG_ON(xa, entry != NULL);
}
- xa_erase_index(xa, j);
+ xa_erase_index(test, xa, j);
XA_BUG_ON(xa, xa_get_mark(xa, j, XA_MARK_0));
XA_BUG_ON(xa, !xa_get_mark(xa, i, XA_MARK_0));
}
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
XA_BUG_ON(xa, xa_get_mark(xa, i, XA_MARK_0));
}
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_find_2(struct xarray *xa)
+static noinline void check_find_2(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
void *entry;
unsigned long i, j, index;
@@ -1303,8 +1358,10 @@ static noinline void check_find_2(struct xarray *xa)
xa_destroy(xa);
}
-static noinline void check_find_3(struct xarray *xa)
+static noinline void check_find_3(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
unsigned long i, j, k;
void *entry;
@@ -1328,8 +1385,10 @@ static noinline void check_find_3(struct xarray *xa)
xa_destroy(xa);
}
-static noinline void check_find_4(struct xarray *xa)
+static noinline void check_find_4(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long index = 0;
void *entry;
@@ -1341,22 +1400,22 @@ static noinline void check_find_4(struct xarray *xa)
entry = xa_find_after(xa, &index, ULONG_MAX, XA_PRESENT);
XA_BUG_ON(xa, entry);
- xa_erase_index(xa, ULONG_MAX);
+ xa_erase_index(test, xa, ULONG_MAX);
}
-static noinline void check_find(struct xarray *xa)
+static noinline void check_find(struct kunit *test)
{
unsigned i;
- check_find_1(xa);
- check_find_2(xa);
- check_find_3(xa);
- check_find_4(xa);
+ check_find_1(test);
+ check_find_2(test);
+ check_find_3(test);
+ check_find_4(test);
for (i = 2; i < 10; i++)
- check_multi_find_1(xa, i);
- check_multi_find_2(xa);
- check_multi_find_3(xa);
+ check_multi_find_1(test, i);
+ check_multi_find_2(test);
+ check_multi_find_3(test);
}
/* See find_swap_entry() in mm/shmem.c */
@@ -1382,8 +1441,10 @@ static noinline unsigned long xa_find_entry(struct xarray *xa, void *item)
return entry ? xas.xa_index : -1;
}
-static noinline void check_find_entry(struct xarray *xa)
+static noinline void check_find_entry(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
#ifdef CONFIG_XARRAY_MULTI
unsigned int order;
unsigned long offset, index;
@@ -1410,12 +1471,14 @@ static noinline void check_find_entry(struct xarray *xa)
xa_store_index(xa, ULONG_MAX, GFP_KERNEL);
XA_BUG_ON(xa, xa_find_entry(xa, xa) != -1);
XA_BUG_ON(xa, xa_find_entry(xa, xa_mk_index(ULONG_MAX)) != -1);
- xa_erase_index(xa, ULONG_MAX);
+ xa_erase_index(test, xa, ULONG_MAX);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_pause(struct xarray *xa)
+static noinline void check_pause(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
void *entry;
unsigned int order;
@@ -1450,8 +1513,10 @@ static noinline void check_pause(struct xarray *xa)
xa_destroy(xa);
}
-static noinline void check_move_tiny(struct xarray *xa)
+static noinline void check_move_tiny(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
XA_BUG_ON(xa, !xa_empty(xa));
@@ -1468,12 +1533,14 @@ static noinline void check_move_tiny(struct xarray *xa)
XA_BUG_ON(xa, xas_prev(&xas) != xa_mk_index(0));
XA_BUG_ON(xa, xas_prev(&xas) != NULL);
rcu_read_unlock();
- xa_erase_index(xa, 0);
+ xa_erase_index(test, xa, 0);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_move_max(struct xarray *xa)
+static noinline void check_move_max(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
xa_store_index(xa, ULONG_MAX, GFP_KERNEL);
@@ -1489,12 +1556,14 @@ static noinline void check_move_max(struct xarray *xa)
XA_BUG_ON(xa, xas_find(&xas, ULONG_MAX) != NULL);
rcu_read_unlock();
- xa_erase_index(xa, ULONG_MAX);
+ xa_erase_index(test, xa, ULONG_MAX);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_move_small(struct xarray *xa, unsigned long idx)
+static noinline void check_move_small(struct kunit *test, unsigned long idx)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
unsigned long i;
@@ -1536,13 +1605,15 @@ static noinline void check_move_small(struct xarray *xa, unsigned long idx)
XA_BUG_ON(xa, xas.xa_index != ULONG_MAX);
rcu_read_unlock();
- xa_erase_index(xa, 0);
- xa_erase_index(xa, idx);
+ xa_erase_index(test, xa, 0);
+ xa_erase_index(test, xa, idx);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_move(struct xarray *xa)
+static noinline void check_move(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, (1 << 16) - 1);
unsigned long i;
@@ -1569,7 +1640,7 @@ static noinline void check_move(struct xarray *xa)
rcu_read_unlock();
for (i = (1 << 8); i < (1 << 15); i++)
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
i = xas.xa_index;
@@ -1600,17 +1671,17 @@ static noinline void check_move(struct xarray *xa)
xa_destroy(xa);
- check_move_tiny(xa);
- check_move_max(xa);
+ check_move_tiny(test);
+ check_move_max(test);
for (i = 0; i < 16; i++)
- check_move_small(xa, 1UL << i);
+ check_move_small(test, 1UL << i);
for (i = 2; i < 16; i++)
- check_move_small(xa, (1UL << i) - 1);
+ check_move_small(test, (1UL << i) - 1);
}
-static noinline void xa_store_many_order(struct xarray *xa,
+static noinline void xa_store_many_order(struct kunit *test, struct xarray *xa,
unsigned long index, unsigned order)
{
XA_STATE_ORDER(xas, xa, index, order);
@@ -1633,30 +1704,34 @@ static noinline void xa_store_many_order(struct xarray *xa,
XA_BUG_ON(xa, xas_error(&xas));
}
-static noinline void check_create_range_1(struct xarray *xa,
+static noinline void check_create_range_1(struct kunit *test,
unsigned long index, unsigned order)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long i;
- xa_store_many_order(xa, index, order);
+ xa_store_many_order(test, xa, index, order);
for (i = index; i < index + (1UL << order); i++)
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_create_range_2(struct xarray *xa, unsigned order)
+static noinline void check_create_range_2(struct kunit *test, unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long i;
unsigned long nr = 1UL << order;
for (i = 0; i < nr * nr; i += nr)
- xa_store_many_order(xa, i, order);
+ xa_store_many_order(test, xa, i, order);
for (i = 0; i < nr * nr; i++)
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_create_range_3(void)
+static noinline void check_create_range_3(struct kunit *test)
{
XA_STATE(xas, NULL, 0);
xas_set_err(&xas, -EEXIST);
@@ -1664,9 +1739,11 @@ static noinline void check_create_range_3(void)
XA_BUG_ON(NULL, xas_error(&xas) != -EEXIST);
}
-static noinline void check_create_range_4(struct xarray *xa,
+static noinline void check_create_range_4(struct kunit *test,
unsigned long index, unsigned order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE_ORDER(xas, xa, index, order);
unsigned long base = xas.xa_index;
unsigned long i = 0;
@@ -1692,13 +1769,15 @@ static noinline void check_create_range_4(struct xarray *xa,
XA_BUG_ON(xa, xas_error(&xas));
for (i = base; i < base + (1UL << order); i++)
- xa_erase_index(xa, i);
+ xa_erase_index(test, xa, i);
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_create_range_5(struct xarray *xa,
+static noinline void check_create_range_5(struct kunit *test,
unsigned long index, unsigned int order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE_ORDER(xas, xa, index, order);
unsigned int i;
@@ -1715,44 +1794,46 @@ static noinline void check_create_range_5(struct xarray *xa,
xa_destroy(xa);
}
-static noinline void check_create_range(struct xarray *xa)
+static noinline void check_create_range(struct kunit *test)
{
unsigned int order;
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 12 : 1;
for (order = 0; order < max_order; order++) {
- check_create_range_1(xa, 0, order);
- check_create_range_1(xa, 1U << order, order);
- check_create_range_1(xa, 2U << order, order);
- check_create_range_1(xa, 3U << order, order);
- check_create_range_1(xa, 1U << 24, order);
+ check_create_range_1(test, 0, order);
+ check_create_range_1(test, 1U << order, order);
+ check_create_range_1(test, 2U << order, order);
+ check_create_range_1(test, 3U << order, order);
+ check_create_range_1(test, 1U << 24, order);
if (order < 10)
- check_create_range_2(xa, order);
-
- check_create_range_4(xa, 0, order);
- check_create_range_4(xa, 1U << order, order);
- check_create_range_4(xa, 2U << order, order);
- check_create_range_4(xa, 3U << order, order);
- check_create_range_4(xa, 1U << 24, order);
-
- check_create_range_4(xa, 1, order);
- check_create_range_4(xa, (1U << order) + 1, order);
- check_create_range_4(xa, (2U << order) + 1, order);
- check_create_range_4(xa, (2U << order) - 1, order);
- check_create_range_4(xa, (3U << order) + 1, order);
- check_create_range_4(xa, (3U << order) - 1, order);
- check_create_range_4(xa, (1U << 24) + 1, order);
-
- check_create_range_5(xa, 0, order);
- check_create_range_5(xa, (1U << order), order);
+ check_create_range_2(test, order);
+
+ check_create_range_4(test, 0, order);
+ check_create_range_4(test, 1U << order, order);
+ check_create_range_4(test, 2U << order, order);
+ check_create_range_4(test, 3U << order, order);
+ check_create_range_4(test, 1U << 24, order);
+
+ check_create_range_4(test, 1, order);
+ check_create_range_4(test, (1U << order) + 1, order);
+ check_create_range_4(test, (2U << order) + 1, order);
+ check_create_range_4(test, (2U << order) - 1, order);
+ check_create_range_4(test, (3U << order) + 1, order);
+ check_create_range_4(test, (3U << order) - 1, order);
+ check_create_range_4(test, (1U << 24) + 1, order);
+
+ check_create_range_5(test, 0, order);
+ check_create_range_5(test, (1U << order), order);
}
- check_create_range_3();
+ check_create_range_3(test);
}
-static noinline void __check_store_range(struct xarray *xa, unsigned long first,
+static noinline void __check_store_range(struct kunit *test, unsigned long first,
unsigned long last)
{
+ struct xarray *xa = xa_param(test);
+
#ifdef CONFIG_XARRAY_MULTI
xa_store_range(xa, first, last, xa_mk_index(first), GFP_KERNEL);
@@ -1767,26 +1848,28 @@ static noinline void __check_store_range(struct xarray *xa, unsigned long first,
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_store_range(struct xarray *xa)
+static noinline void check_store_range(struct kunit *test)
{
unsigned long i, j;
for (i = 0; i < 128; i++) {
for (j = i; j < 128; j++) {
- __check_store_range(xa, i, j);
- __check_store_range(xa, 128 + i, 128 + j);
- __check_store_range(xa, 4095 + i, 4095 + j);
- __check_store_range(xa, 4096 + i, 4096 + j);
- __check_store_range(xa, 123456 + i, 123456 + j);
- __check_store_range(xa, (1 << 24) + i, (1 << 24) + j);
+ __check_store_range(test, i, j);
+ __check_store_range(test, 128 + i, 128 + j);
+ __check_store_range(test, 4095 + i, 4095 + j);
+ __check_store_range(test, 4096 + i, 4096 + j);
+ __check_store_range(test, 123456 + i, 123456 + j);
+ __check_store_range(test, (1 << 24) + i, (1 << 24) + j);
}
}
}
#ifdef CONFIG_XARRAY_MULTI
-static void check_split_1(struct xarray *xa, unsigned long index,
+static void check_split_1(struct kunit *test, unsigned long index,
unsigned int order, unsigned int new_order)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE_ORDER(xas, xa, index, new_order);
unsigned int i, found;
void *entry;
@@ -1822,26 +1905,30 @@ static void check_split_1(struct xarray *xa, unsigned long index,
xa_destroy(xa);
}
-static noinline void check_split(struct xarray *xa)
+static noinline void check_split(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int order, new_order;
XA_BUG_ON(xa, !xa_empty(xa));
for (order = 1; order < 2 * XA_CHUNK_SHIFT; order++) {
for (new_order = 0; new_order < order; new_order++) {
- check_split_1(xa, 0, order, new_order);
- check_split_1(xa, 1UL << order, order, new_order);
- check_split_1(xa, 3UL << order, order, new_order);
+ check_split_1(test, 0, order, new_order);
+ check_split_1(test, 1UL << order, order, new_order);
+ check_split_1(test, 3UL << order, order, new_order);
}
}
}
#else
-static void check_split(struct xarray *xa) { }
+static void check_split(struct kunit *test) { }
#endif
-static void check_align_1(struct xarray *xa, char *name)
+static void check_align_1(struct kunit *test, char *name)
{
+ struct xarray *xa = xa_param(test);
+
int i;
unsigned int id;
unsigned long index;
@@ -1861,8 +1948,10 @@ static void check_align_1(struct xarray *xa, char *name)
* We should always be able to store without allocating memory after
* reserving a slot.
*/
-static void check_align_2(struct xarray *xa, char *name)
+static void check_align_2(struct kunit *test, char *name)
{
+ struct xarray *xa = xa_param(test);
+
int i;
XA_BUG_ON(xa, !xa_empty(xa));
@@ -1881,15 +1970,15 @@ static void check_align_2(struct xarray *xa, char *name)
XA_BUG_ON(xa, !xa_empty(xa));
}
-static noinline void check_align(struct xarray *xa)
+static noinline void check_align(struct kunit *test)
{
char name[] = "Motorola 68000";
- check_align_1(xa, name);
- check_align_1(xa, name + 1);
- check_align_1(xa, name + 2);
- check_align_1(xa, name + 3);
- check_align_2(xa, name);
+ check_align_1(test, name);
+ check_align_1(test, name + 1);
+ check_align_1(test, name + 2);
+ check_align_1(test, name + 3);
+ check_align_2(test, name);
}
static LIST_HEAD(shadow_nodes);
@@ -1905,7 +1994,7 @@ static void test_update_node(struct xa_node *node)
}
}
-static noinline void shadow_remove(struct xarray *xa)
+static noinline void shadow_remove(struct kunit *test, struct xarray *xa)
{
struct xa_node *node;
@@ -1919,8 +2008,17 @@ static noinline void shadow_remove(struct xarray *xa)
xa_unlock(xa);
}
-static noinline void check_workingset(struct xarray *xa, unsigned long index)
+struct workingset_testcase {
+ struct xarray *xa;
+ unsigned long index;
+};
+
+static noinline void check_workingset(struct kunit *test)
{
+ struct workingset_testcase tc = *(struct workingset_testcase *)test->param_value;
+ struct xarray *xa = tc.xa;
+ unsigned long index = tc.index;
+
XA_STATE(xas, xa, index);
xas_set_update(&xas, test_update_node);
@@ -1943,7 +2041,7 @@ static noinline void check_workingset(struct xarray *xa, unsigned long index)
xas_unlock(&xas);
XA_BUG_ON(xa, list_empty(&shadow_nodes));
- shadow_remove(xa);
+ shadow_remove(test, xa);
XA_BUG_ON(xa, !list_empty(&shadow_nodes));
XA_BUG_ON(xa, !xa_empty(xa));
}
@@ -1952,9 +2050,11 @@ static noinline void check_workingset(struct xarray *xa, unsigned long index)
* Check that the pointer / value / sibling entries are accounted the
* way we expect them to be.
*/
-static noinline void check_account(struct xarray *xa)
+static noinline void check_account(struct kunit *test)
{
#ifdef CONFIG_XARRAY_MULTI
+ struct xarray *xa = xa_param(test);
+
unsigned int order;
for (order = 1; order < 12; order++) {
@@ -1981,8 +2081,10 @@ static noinline void check_account(struct xarray *xa)
#endif
}
-static noinline void check_get_order(struct xarray *xa)
+static noinline void check_get_order(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 20 : 1;
unsigned int order;
unsigned long i, j;
@@ -2001,8 +2103,10 @@ static noinline void check_get_order(struct xarray *xa)
}
}
-static noinline void check_xas_get_order(struct xarray *xa)
+static noinline void check_xas_get_order(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
unsigned int max_order = IS_ENABLED(CONFIG_XARRAY_MULTI) ? 20 : 1;
@@ -2034,8 +2138,10 @@ static noinline void check_xas_get_order(struct xarray *xa)
}
}
-static noinline void check_xas_conflict_get_order(struct xarray *xa)
+static noinline void check_xas_conflict_get_order(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
XA_STATE(xas, xa, 0);
void *entry;
@@ -2092,8 +2198,10 @@ static noinline void check_xas_conflict_get_order(struct xarray *xa)
}
-static noinline void check_destroy(struct xarray *xa)
+static noinline void check_destroy(struct kunit *test)
{
+ struct xarray *xa = xa_param(test);
+
unsigned long index;
XA_BUG_ON(xa, !xa_empty(xa));
@@ -2126,52 +2234,59 @@ static noinline void check_destroy(struct xarray *xa)
}
static DEFINE_XARRAY(array);
+static struct xarray *arrays[] = { &array };
+KUNIT_ARRAY_PARAM(array, arrays, NULL);
+
+static struct xarray *xa0s[] = { &xa0 };
+KUNIT_ARRAY_PARAM(xa0, xa0s, NULL);
+
+static struct workingset_testcase workingset_testcases[] = {
+ { &array, 0 },
+ { &array, 64 },
+ { &array, 4096 },
+};
+KUNIT_ARRAY_PARAM(workingset, workingset_testcases, NULL);
+
+static struct kunit_case xarray_cases[] = {
+ KUNIT_CASE_PARAM(check_xa_err, array_gen_params),
+ KUNIT_CASE_PARAM(check_xas_retry, array_gen_params),
+ KUNIT_CASE_PARAM(check_xa_load, array_gen_params),
+ KUNIT_CASE_PARAM(check_xa_mark, array_gen_params),
+ KUNIT_CASE_PARAM(check_xa_shrink, array_gen_params),
+ KUNIT_CASE_PARAM(check_xas_erase, array_gen_params),
+ KUNIT_CASE_PARAM(check_insert, array_gen_params),
+ KUNIT_CASE_PARAM(check_cmpxchg, array_gen_params),
+ KUNIT_CASE_PARAM(check_cmpxchg_order, array_gen_params),
+ KUNIT_CASE_PARAM(check_reserve, array_gen_params),
+ KUNIT_CASE_PARAM(check_reserve, xa0_gen_params),
+ KUNIT_CASE_PARAM(check_multi_store, array_gen_params),
+ KUNIT_CASE_PARAM(check_multi_store_advanced, array_gen_params),
+ KUNIT_CASE_PARAM(check_get_order, array_gen_params),
+ KUNIT_CASE_PARAM(check_xas_get_order, array_gen_params),
+ KUNIT_CASE_PARAM(check_xas_conflict_get_order, array_gen_params),
+ KUNIT_CASE(check_xa_alloc),
+ KUNIT_CASE_PARAM(check_find, array_gen_params),
+ KUNIT_CASE_PARAM(check_find_entry, array_gen_params),
+ KUNIT_CASE_PARAM(check_pause, array_gen_params),
+ KUNIT_CASE_PARAM(check_account, array_gen_params),
+ KUNIT_CASE_PARAM(check_destroy, array_gen_params),
+ KUNIT_CASE_PARAM(check_move, array_gen_params),
+ KUNIT_CASE_PARAM(check_create_range, array_gen_params),
+ KUNIT_CASE_PARAM(check_store_range, array_gen_params),
+ KUNIT_CASE_PARAM(check_store_iter, array_gen_params),
+ KUNIT_CASE_PARAM(check_align, xa0_gen_params),
+ KUNIT_CASE_PARAM(check_split, array_gen_params),
+ KUNIT_CASE_PARAM(check_workingset, workingset_gen_params),
+ {},
+};
+
+static struct kunit_suite xarray_suite = {
+ .name = "xarray",
+ .test_cases = xarray_cases,
+};
+
+kunit_test_suite(xarray_suite);
-static int xarray_checks(void)
-{
- check_xa_err(&array);
- check_xas_retry(&array);
- check_xa_load(&array);
- check_xa_mark(&array);
- check_xa_shrink(&array);
- check_xas_erase(&array);
- check_insert(&array);
- check_cmpxchg(&array);
- check_cmpxchg_order(&array);
- check_reserve(&array);
- check_reserve(&xa0);
- check_multi_store(&array);
- check_multi_store_advanced(&array);
- check_get_order(&array);
- check_xas_get_order(&array);
- check_xas_conflict_get_order(&array);
- check_xa_alloc();
- check_find(&array);
- check_find_entry(&array);
- check_pause(&array);
- check_account(&array);
- check_destroy(&array);
- check_move(&array);
- check_create_range(&array);
- check_store_range(&array);
- check_store_iter(&array);
- check_align(&xa0);
- check_split(&array);
-
- check_workingset(&array, 0);
- check_workingset(&array, 64);
- check_workingset(&array, 4096);
-
- printk("XArray: %u of %u tests passed\n", tests_passed, tests_run);
- return (tests_run == tests_passed) ? 0 : -EINVAL;
-}
-
-static void xarray_exit(void)
-{
-}
-
-module_init(xarray_checks);
-module_exit(xarray_exit);
MODULE_AUTHOR("Matthew Wilcox <willy@infradead.org>");
MODULE_DESCRIPTION("XArray API test module");
MODULE_LICENSE("GPL");
---
base-commit: ac0019f46558a127f874d0c602686af7ae498773
change-id: 20241204-xarray-kunit-port-87e6161bc1ab
Best regards,
--
Tamir Duberstein <tamird@gmail.com>+ Liam, Matthew
Hello,
I believe this patch needs to be reverted for now as it breaks the
user-space build of /tools/testing/radix-tree with:
In file included from xarray.c:11:
../../../lib/test_xarray.c:9:10: fatal error: kunit/test.h: No such file
or directory
9 | #include <kunit/test.h>
| ^~~~~~~~~~~~~~
compilation terminated.
make: *** [<builtin>: xarray.o] Error 1
make: *** Waiting for unfinished jobs....
this then prevents the maple tree test suite from building.
Thanks,
Sid
* Sidhartha Kumar <sidhartha.kumar@oracle.com> [250129 16:02]: > + Liam, Matthew + linux-mm Thank you Sid. > > Hello, > > I believe this patch needs to be reverted for now as it breaks the > user-space build of /tools/testing/radix-tree with: > > In file included from xarray.c:11: > ../../../lib/test_xarray.c:9:10: fatal error: kunit/test.h: No such file > or directory > 9 | #include <kunit/test.h> > | ^~~~~~~~~~~~~~ > compilation terminated. > make: *** [<builtin>: xarray.o] Error 1 > make: *** Waiting for unfinished jobs.... > > this then prevents the maple tree test suite from building. How are grammar corrections going to the right person (but not the mailing list) while an entire conversion to kunit is not [1]? Does the patch really need to drop the module testing too? What exactly is the point of converting one testing system to another besides disruption of actual work? Who asked for this? What is the point? Is anyone doing work on the xarray running the kunit tests? This should be reverted as it should never have been merged. Regards, Liam [1]. https://lore.kernel.org/all/20241009193602.41797-2-tamird@gmail.com/
On Wed, Jan 29, 2025 at 4:26 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote: > > * Sidhartha Kumar <sidhartha.kumar@oracle.com> [250129 16:02]: > > + Liam, Matthew > > + linux-mm > > Thank you Sid. > > > > > Hello, > > > > I believe this patch needs to be reverted for now as it breaks the > > user-space build of /tools/testing/radix-tree with: > > > > In file included from xarray.c:11: > > ../../../lib/test_xarray.c:9:10: fatal error: kunit/test.h: No such file > > or directory > > 9 | #include <kunit/test.h> > > | ^~~~~~~~~~~~~~ > > compilation terminated. > > make: *** [<builtin>: xarray.o] Error 1 > > make: *** Waiting for unfinished jobs.... > > > > this then prevents the maple tree test suite from building. > > How are grammar corrections going to the right person (but not the > mailing list) while an entire conversion to kunit is not [1]? Very simple: the tests are not properly included in MAINTAINERS. I sent https://lore.kernel.org/all/20250129-xarray-test-maintainer-v1-1-482e31f30f47@gmail.com/ a few minutes ago for this reason. > Does the patch really need to drop the module testing too? > > What exactly is the point of converting one testing system to another > besides disruption of actual work? Who asked for this? What is the > point? All this is described in the commit message. > Is anyone doing work on the xarray running the kunit tests? I was doing work on xarray and I was running the kunit tests. > This should be reverted as it should never have been merged. > > Regards, > Liam > > [1]. https://lore.kernel.org/all/20241009193602.41797-2-tamird@gmail.com/
On Wed, 29 Jan 2025 16:28:32 -0500 Tamir Duberstein <tamird@gmail.com> wrote: > > How are grammar corrections going to the right person (but not the > > mailing list) while an entire conversion to kunit is not [1]? > > Very simple: the tests are not properly included in MAINTAINERS. I > sent https://lore.kernel.org/all/20250129-xarray-test-maintainer-v1-1-482e31f30f47@gmail.com/ > a few minutes ago for this reason. I failed to notice that this patch didn't cc linux-mm. MAINTAINERS doesn't ask people to cc linux-mm on xarray changes. linux-mm averages 130 messages/day - I think it's reasonable to believe that MM developers spend a few minutes a day scanning the Subject:s. This: From: Andrew Morton <akpm@linux-foundation.org> Subject: MAINTAINERS: include linux-mm for xarray maintenance Date: Thu Jan 30 04:16:20 PM PST 2025 MM developers have an interest in the xarray code. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) --- a/MAINTAINERS~maintainers-include-linux-mm-for-xarray-maintenance +++ a/MAINTAINERS @@ -25676,6 +25676,7 @@ F: arch/x86/entry/vdso/ XARRAY M: Matthew Wilcox <willy@infradead.org> L: linux-fsdevel@vger.kernel.org +L: linux-mm@kvack.org S: Supported F: Documentation/core-api/xarray.rst F: include/linux/idr.h _
* Tamir Duberstein <tamird@gmail.com> [250129 16:29]:
> On Wed, Jan 29, 2025 at 4:26 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> >
> > * Sidhartha Kumar <sidhartha.kumar@oracle.com> [250129 16:02]:
> > > + Liam, Matthew
> >
> > + linux-mm
> >
> > Thank you Sid.
> >
> > >
> > > Hello,
> > >
> > > I believe this patch needs to be reverted for now as it breaks the
> > > user-space build of /tools/testing/radix-tree with:
> > >
> > > In file included from xarray.c:11:
> > > ../../../lib/test_xarray.c:9:10: fatal error: kunit/test.h: No such file
> > > or directory
> > > 9 | #include <kunit/test.h>
> > > | ^~~~~~~~~~~~~~
> > > compilation terminated.
> > > make: *** [<builtin>: xarray.o] Error 1
> > > make: *** Waiting for unfinished jobs....
> > >
> > > this then prevents the maple tree test suite from building.
> >
> > How are grammar corrections going to the right person (but not the
> > mailing list) while an entire conversion to kunit is not [1]?
>
> Very simple: the tests are not properly included in MAINTAINERS. I
> sent https://lore.kernel.org/all/20250129-xarray-test-maintainer-v1-1-482e31f30f47@gmail.com/
> a few minutes ago for this reason.
Fair enough, but from the patch:
@@ -6,11 +6,10 @@
* Author: Matthew Wilcox <willy@infradead.org>
*/
-#include <linux/xarray.h>
-#include <linux/module.h>
+#include <kunit/test.h>
...
-module_init(xarray_checks);
-module_exit(xarray_exit);
MODULE_AUTHOR("Matthew Wilcox <willy@infradead.org>");
MODULE_DESCRIPTION("XArray API test module");
MODULE_LICENSE("GPL");
I don't get why the huge list of Cc's didn't include the author who is
in the git commit signers:
$ ./scripts/get_maintainer.pl --git lib/xarray.c
Matthew Wilcox <willy@infradead.org> (supporter:XARRAY,commit_signer:1/3=33%,authored:1/3=33%,added_lines:19/52=37%,removed_lines:4/23=17%)
Andrew Morton <akpm@linux-foundation.org> (supporter:LIBRARY CODE,commit_signer:3/3=100%)
...
>
> > Does the patch really need to drop the module testing too?
> >
> > What exactly is the point of converting one testing system to another
> > besides disruption of actual work? Who asked for this? What is the
> > point?
>
> All this is described in the commit message.
The commit message says you like the output more and implies you like
the command better.
I've never used the kunit testing of xarray and have used the userspace
testing instead, so I can't speak to the obscure invocation as both
commands seem insanely long and obscure to me.
>
> > Is anyone doing work on the xarray running the kunit tests?
>
> I was doing work on xarray and I was running the kunit tests.
...
You should look at the userspace testing (that this broke) as it has
been really useful in certain scenarios.
Thanks,
Liam
Hi Liam,
On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> I've never used the kunit testing of xarray and have used the userspace
> testing instead, so I can't speak to the obscure invocation as both
> commands seem insanely long and obscure to me.
The long and obscure command line is a red herring: a simple
"modprobe test_xarray" is all it takes...
> You should look at the userspace testing (that this broke) as it has
> been really useful in certain scenarios.
BTW, how do I even build tools/testing/radix-tree?
"make tools/help" doesn't show the radix-tree test.
"make tools/all" doesn't seem to try to build it.
Same for "make kselftest-all".
When trying the above, and ignoring failures due to missing packages
on my host:
- there are several weird build errors,
- this doesn't play well with O=,
- lots of scary warnings when building for 32-bit,
- ...
At least the kunit tests build (and run[1] ;-) most of the time...
[1] test_xarray started failing on m68k recently
https://lore.kernel.org/all/CAMuHMdU_bfadUO=0OZ=AoQ9EAmQPA4wsLCBqohXR+QCeCKRn4A@mail.gmail.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Jan 30, 2025 at 09:21:12AM +0100, Geert Uytterhoeven wrote: > The long and obscure command line is a red herring: a simple > "modprobe test_xarray" is all it takes... That's all I've ever done. I'm confused/annoyed by all this "let's wrap everything up in some complex and obscure new thing" practice. > > You should look at the userspace testing (that this broke) as it has > > been really useful in certain scenarios. > > BTW, how do I even build tools/testing/radix-tree? > "make tools/help" doesn't show the radix-tree test. > "make tools/all" doesn't seem to try to build it. > Same for "make kselftest-all". I've never heard of any of those things. So I didn't try to make any of them work. > When trying the above, and ignoring failures due to missing packages > on my host: > - there are several weird build errors, > - this doesn't play well with O=, > - lots of scary warnings when building for 32-bit, > - ... Really? Turns out I haven't built for 32-bit on this laptop, so I'm installing all the packages I need now. I seem to reemember it being painful due to liburcu packaging not allowing me to install both a 32-bit and 64-bit package at the same time. > At least the kunit tests build (and run[1] ;-) most of the time... That's unworthy. kunit isn't trying to do anything nearly as hard as the radix tree tests are. > [1] test_xarray started failing on m68k recently > https://lore.kernel.org/all/CAMuHMdU_bfadUO=0OZ=AoQ9EAmQPA4wsLCBqohXR+QCeCKRn4A@mail.gmail.com/ I really wish Andrew would stop merging xarray patches.
* Geert Uytterhoeven <geert@linux-m68k.org> [250130 03:21]:
> Hi Liam,
>
> On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > I've never used the kunit testing of xarray and have used the userspace
> > testing instead, so I can't speak to the obscure invocation as both
> > commands seem insanely long and obscure to me.
>
> The long and obscure command line is a red herring: a simple
> "modprobe test_xarray" is all it takes...
That command worked before too...
>
> > You should look at the userspace testing (that this broke) as it has
> > been really useful in certain scenarios.
>
> BTW, how do I even build tools/testing/radix-tree?
> "make tools/help" doesn't show the radix-tree test.
> "make tools/all" doesn't seem to try to build it.
> Same for "make kselftest-all".
make
Or look at the make file and stop guessing. Considering how difficult
it is to get m68k to build, you should probably know how to read a
makefile.
> When trying the above, and ignoring failures due to missing packages
> on my host:
> - there are several weird build errors,
> - this doesn't play well with O=,
> - lots of scary warnings when building for 32-bit,
> - ...
>
> At least the kunit tests build (and run[1] ;-) most of the time...
Do they? How about you break something in xarray and then try to boot
the kunit, or try to boot to load that module.
This exchange is a good argument against doing any kunit work on my
tests.
>
> [1] test_xarray started failing on m68k recently
> https://lore.kernel.org/all/CAMuHMdU_bfadUO=0OZ=AoQ9EAmQPA4wsLCBqohXR+QCeCKRn4A@mail.gmail.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Hi Liam,
On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [250130 03:21]:
> > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > I've never used the kunit testing of xarray and have used the userspace
> > > testing instead, so I can't speak to the obscure invocation as both
> > > commands seem insanely long and obscure to me.
> >
> > The long and obscure command line is a red herring: a simple
> > "modprobe test_xarray" is all it takes...
>
> That command worked before too...
Exactly, great!
> > > You should look at the userspace testing (that this broke) as it has
> > > been really useful in certain scenarios.
> >
> > BTW, how do I even build tools/testing/radix-tree?
> > "make tools/help" doesn't show the radix-tree test.
> > "make tools/all" doesn't seem to try to build it.
> > Same for "make kselftest-all".
>
> make
Where?
> Or look at the make file and stop guessing. Considering how difficult
There is no Makefile referencing tools/testing/radix-tree or the
radix-tree subdir. That's why I asked...
Oh, I am supposed to run make in tools/testing/radix-tree/?
What a surprise!
Which is a pain when building in a separate output directory, as you
cannot just do "make -C tools/testing/radix-tree" there, but have to
type the full "make -C tools/testing/radix-tree O=..." (and optionally
ARCH=... and CROSS_COMPILE=...; oh wait, these are ignored :-( in the
source directory instead...
If these tests are not integrated into the normal build system (see
also [1]), I am not so surprised the auto-builders don't build them,
and breakages are introduced...
> it is to get m68k to build, you should probably know how to read a
> makefile.
Like all other kernel cross-compilation? Usually you don't even have
to know where your cross-compiler is living:
make ARCH=m68k
> > When trying the above, and ignoring failures due to missing packages
> > on my host:
> > - there are several weird build errors,
> > - this doesn't play well with O=,
> > - lots of scary warnings when building for 32-bit,
> > - ...
> >
> > At least the kunit tests build (and run[1] ;-) most of the time...
>
> Do they? How about you break something in xarray and then try to boot
> the kunit, or try to boot to load that module.
If you break the kernel beyond the point of booting, you can indeed
not run any test modules...
Which does _not_ mean the userspace tests are not useful, and that I
approve breaking the userspace tests...
[1] https://lore.kernel.org/all/CAK7LNASdA+5_pdTjr1dY-cKGSDq804Huc_CX_8-Gg+ypFCmajQ@mail.gmail.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Geert,
Having written a ton of test code, I've unfortunately encountered a lot of
this sort of push-back and it's HUGELY off-putting. Writing test code
should be ENCOURAGED not litigated against.
The truth is far too little kernel code is tested to any degree, and this
is part of why.
On kunit collaboration, I attended an in-person talk at LPC on kunit
userland testing where it was broadly agreed that at this point in time,
the xarray/radix tree tests weren't really suited to the framework.
Therefore I think the healthy means of pushing forward with integration is
in sensible discussion and if patches, RFC patches in collaboration with
authors.
The unhealthy approach is to needle one of the biggest contributors to core
test code in the kernel on a thread because you don't seem to want to cd to
a directory and run make.
Why is this relevant to me? I am the author of the VMA test suite, on which
I spent countless hours + relied heavily on Liam's work to do so, and
equally there you have to cd to a directory and run make.
But at the same time in both cases, testability of key internal components
is ENORMOUSLY improved and allows for REALLY exciting possibilities in test
coverage, really isolating functions for unit testing, enormously fast
iteration speed, etc. etc.
I ask you to weigh up the desire to enumerate your misgivings about the
testing approach used here vs. all of the above.
I would respectfully suggest that here is neither the time nor the place
for splitting hairs.
Thanks, Lorenzo
On Thu, Jan 30, 2025 at 02:25:57PM +0100, Geert Uytterhoeven wrote:
> Hi Liam,
>
> On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > * Geert Uytterhoeven <geert@linux-m68k.org> [250130 03:21]:
> > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > > I've never used the kunit testing of xarray and have used the userspace
> > > > testing instead, so I can't speak to the obscure invocation as both
> > > > commands seem insanely long and obscure to me.
> > >
> > > The long and obscure command line is a red herring: a simple
> > > "modprobe test_xarray" is all it takes...
> >
> > That command worked before too...
>
> Exactly, great!
>
> > > > You should look at the userspace testing (that this broke) as it has
> > > > been really useful in certain scenarios.
> > >
> > > BTW, how do I even build tools/testing/radix-tree?
> > > "make tools/help" doesn't show the radix-tree test.
> > > "make tools/all" doesn't seem to try to build it.
> > > Same for "make kselftest-all".
> >
> > make
>
> Where?
>
> > Or look at the make file and stop guessing. Considering how difficult
>
> There is no Makefile referencing tools/testing/radix-tree or the
> radix-tree subdir. That's why I asked...
>
> Oh, I am supposed to run make in tools/testing/radix-tree/?
> What a surprise!
>
> Which is a pain when building in a separate output directory, as you
> cannot just do "make -C tools/testing/radix-tree" there, but have to
> type the full "make -C tools/testing/radix-tree O=..." (and optionally
> ARCH=... and CROSS_COMPILE=...; oh wait, these are ignored :-( in the
> source directory instead...
>
> If these tests are not integrated into the normal build system (see
> also [1]), I am not so surprised the auto-builders don't build them,
> and breakages are introduced...
>
> > it is to get m68k to build, you should probably know how to read a
> > makefile.
>
> Like all other kernel cross-compilation? Usually you don't even have
> to know where your cross-compiler is living:
>
> make ARCH=m68k
>
> > > When trying the above, and ignoring failures due to missing packages
> > > on my host:
> > > - there are several weird build errors,
> > > - this doesn't play well with O=,
> > > - lots of scary warnings when building for 32-bit,
> > > - ...
> > >
> > > At least the kunit tests build (and run[1] ;-) most of the time...
> >
> > Do they? How about you break something in xarray and then try to boot
> > the kunit, or try to boot to load that module.
>
> If you break the kernel beyond the point of booting, you can indeed
> not run any test modules...
>
> Which does _not_ mean the userspace tests are not useful, and that I
> approve breaking the userspace tests...
>
> [1] https://lore.kernel.org/all/CAK7LNASdA+5_pdTjr1dY-cKGSDq804Huc_CX_8-Gg+ypFCmajQ@mail.gmail.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Hi Lorenzo,
On Thu, 30 Jan 2025 at 15:09, Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
> Having written a ton of test code, I've unfortunately encountered a lot of
> this sort of push-back and it's HUGELY off-putting. Writing test code
> should be ENCOURAGED not litigated against.
I am not discouraging nor pushing back on any testing code (on the
contrary, I test every single new kunit test that appears upstream).
My apologies if I gave the impression.
> The truth is far too little kernel code is tested to any degree, and this
> is part of why.
>
> On kunit collaboration, I attended an in-person talk at LPC on kunit
> userland testing where it was broadly agreed that at this point in time,
> the xarray/radix tree tests weren't really suited to the framework.
>
> Therefore I think the healthy means of pushing forward with integration is
> in sensible discussion and if patches, RFC patches in collaboration with
> authors.
Good.
> The unhealthy approach is to needle one of the biggest contributors to core
> test code in the kernel on a thread because you don't seem to want to cd to
> a directory and run make.
My initial issue was that I could not find out where that is documented.
$ make help
...
Userspace tools targets:
use "make tools/help"
or "cd tools; make help"
$ make tools/help
Possible targets:
...
You can do:
...
$ make tools/all
builds all tools.
But that command does not build tools/testing/radix-tree, so I was
completely lost.
> Why is this relevant to me? I am the author of the VMA test suite, on which
> I spent countless hours + relied heavily on Liam's work to do so, and
> equally there you have to cd to a directory and run make.
Thanks for your work! One suggestion for improvement: tools/testing/vma
does not seem to be built by "make tools/all" either.
> But at the same time in both cases, testability of key internal components
> is ENORMOUSLY improved and allows for REALLY exciting possibilities in test
> coverage, really isolating functions for unit testing, enormously fast
> iteration speed, etc. etc.
>
> I ask you to weigh up the desire to enumerate your misgivings about the
> testing approach used here vs. all of the above.
I repeat: I am not against these tests.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Jan 30, 2025 at 03:38:36PM +0100, Geert Uytterhoeven wrote:
> Hi Lorenzo,
>
> On Thu, 30 Jan 2025 at 15:09, Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> > Having written a ton of test code, I've unfortunately encountered a lot of
> > this sort of push-back and it's HUGELY off-putting. Writing test code
> > should be ENCOURAGED not litigated against.
>
> I am not discouraging nor pushing back on any testing code (on the
> contrary, I test every single new kunit test that appears upstream).
> My apologies if I gave the impression.
My point is what comes across as pedantry often seems to arrive (in my
experience) in response to test code submissions.
A wag would say 'isn't that true of all kernel code?' :) but my experience
has been that there has been poor RoI on the kind of feedback you get
vs. meaningful benefits to the point that it feels like letting yourself in
for yak shaving.
We may be terribly misreading you in this thread, but it's in any case how
it comes across. Obviously this isn't helped by the context of this
discussion!
>
> > The truth is far too little kernel code is tested to any degree, and this
> > is part of why.
> >
> > On kunit collaboration, I attended an in-person talk at LPC on kunit
> > userland testing where it was broadly agreed that at this point in time,
> > the xarray/radix tree tests weren't really suited to the framework.
> >
> > Therefore I think the healthy means of pushing forward with integration is
> > in sensible discussion and if patches, RFC patches in collaboration with
> > authors.
>
> Good.
>
> > The unhealthy approach is to needle one of the biggest contributors to core
> > test code in the kernel on a thread because you don't seem to want to cd to
> > a directory and run make.
>
> My initial issue was that I could not find out where that is documented.
>
> $ make help
> ...
> Userspace tools targets:
> use "make tools/help"
> or "cd tools; make help"
>
> $ make tools/help
> Possible targets:
> ...
> You can do:
> ...
> $ make tools/all
>
> builds all tools.
>
> But that command does not build tools/testing/radix-tree, so I was
> completely lost.
Right, I mean this should be easy enough to fix.
If what you're saying is - make this more discoverable, make this easily
buildable from the top of the tree - then sure, and I expect this shouldn't
be too challenging.
>
> > Why is this relevant to me? I am the author of the VMA test suite, on which
> > I spent countless hours + relied heavily on Liam's work to do so, and
> > equally there you have to cd to a directory and run make.
>
> Thanks for your work! One suggestion for improvement: tools/testing/vma
> does not seem to be built by "make tools/all" either.
You're welcome, and right yeah, should be relatively simple to fix.
This kind of straightforward practical thing is fine. 'You must use the
space wombat with extra fireworks' type feedback is not so much...
>
> > But at the same time in both cases, testability of key internal components
> > is ENORMOUSLY improved and allows for REALLY exciting possibilities in test
> > coverage, really isolating functions for unit testing, enormously fast
> > iteration speed, etc. etc.
> >
> > I ask you to weigh up the desire to enumerate your misgivings about the
> > testing approach used here vs. all of the above.
>
> I repeat: I am not against these tests.
Good, but I would also emphasise what I'm trying to get across with the
wall of text here (sorry, that's very me) - let's not get bogged down in
the framework or whether it might be preferable to have it under kunit or
this that or the other thing vs. the enormous benefits this stuff brings.
Sometimes, esp. with new approaches to testing, it has to be at the very
least incremental.
If you're saying 'just get it documented in a make help and make it
buildable from the top of the tree' then fair enough and hopefully not too
difficult.
In other words - we are all after the same thing here, let's work towards
making everything better, and not unnecessarily throw unshaved yaks in the
way :)
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Cheers, Lorenzo
* Geert Uytterhoeven <geert@linux-m68k.org> [250130 08:26]:
> Hi Liam,
>
> On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > * Geert Uytterhoeven <geert@linux-m68k.org> [250130 03:21]:
> > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > > I've never used the kunit testing of xarray and have used the userspace
> > > > testing instead, so I can't speak to the obscure invocation as both
> > > > commands seem insanely long and obscure to me.
> > >
> > > The long and obscure command line is a red herring: a simple
> > > "modprobe test_xarray" is all it takes...
> >
> > That command worked before too...
>
> Exactly, great!
>
> > > > You should look at the userspace testing (that this broke) as it has
> > > > been really useful in certain scenarios.
> > >
> > > BTW, how do I even build tools/testing/radix-tree?
> > > "make tools/help" doesn't show the radix-tree test.
> > > "make tools/all" doesn't seem to try to build it.
> > > Same for "make kselftest-all".
> >
> > make
>
> Where?
> > > BTW, how do I even build tools/testing/radix-tree?
^^^^^^^^^^^^^^^^^^^^^^^
>
> > Or look at the make file and stop guessing. Considering how difficult
>
> There is no Makefile referencing tools/testing/radix-tree or the
> radix-tree subdir. That's why I asked...
>
> Oh, I am supposed to run make in tools/testing/radix-tree/?
> What a surprise!
>
> Which is a pain when building in a separate output directory, as you
> cannot just do "make -C tools/testing/radix-tree" there, but have to
> type the full "make -C tools/testing/radix-tree O=..." (and optionally
> ARCH=... and CROSS_COMPILE=...; oh wait, these are ignored :-( in the
> source directory instead...
I'll await your patch to link all this together. Please Cc the authors.
>
> If these tests are not integrated into the normal build system (see
> also [1]), I am not so surprised the auto-builders don't build them,
> and breakages are introduced...
>
> > it is to get m68k to build, you should probably know how to read a
> > makefile.
>
> Like all other kernel cross-compilation? Usually you don't even have
> to know where your cross-compiler is living:
>
> make ARCH=m68k
Ignoring that I had to make a config - which asked challenging
questions...
And ignoring the steps to get m68k compiler...
> > > When trying the above, and ignoring failures due to missing packages
> > > on my host:
> > > - there are several weird build errors,
> > > - this doesn't play well with O=,
> > > - lots of scary warnings when building for 32-bit,
> > > - ...
> > >
In file included from ./include/linux/sched.h:12,
from arch/m68k/kernel/asm-offsets.c:15:
./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’
7 | register struct task_struct *current __asm__("%a2");
>
> > > At least the kunit tests build (and run[1] ;-) most of the time...
> >
> > Do they? How about you break something in xarray and then try to boot
> > the kunit, or try to boot to load that module.
>
> If you break the kernel beyond the point of booting, you can indeed
> not run any test modules...
Which is extremely easy when you are changing code that runs so early in
the boot.
My code found a compiler issue because it's the first function that
returns a boolean. This is stupid.
>
> Which does _not_ mean the userspace tests are not useful, and that I
> approve breaking the userspace tests...
Perfect, let's revert the patch then.
This is such a waste of time.
Hi Liam,
On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [250130 08:26]:
> > On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > * Geert Uytterhoeven <geert@linux-m68k.org> [250130 03:21]:
> > > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > > > I've never used the kunit testing of xarray and have used the userspace
> > > > > testing instead, so I can't speak to the obscure invocation as both
> > > > > commands seem insanely long and obscure to me.
> > > >
> > > > The long and obscure command line is a red herring: a simple
> > > > "modprobe test_xarray" is all it takes...
> > >
> > > That command worked before too...
> >
> > Exactly, great!
> >
> > > > > You should look at the userspace testing (that this broke) as it has
> > > > > been really useful in certain scenarios.
> > > >
> > > > BTW, how do I even build tools/testing/radix-tree?
> > > > "make tools/help" doesn't show the radix-tree test.
> > > > "make tools/all" doesn't seem to try to build it.
> > > > Same for "make kselftest-all".
> > >
> > > make
> >
> > Where?
> > > > BTW, how do I even build tools/testing/radix-tree?
> ^^^^^^^^^^^^^^^^^^^^^^^
Things like "make -C drivers/net/ethernet/" stopped working
ca. 20y ago.
> > > Or look at the make file and stop guessing. Considering how difficult
> >
> > There is no Makefile referencing tools/testing/radix-tree or the
> > radix-tree subdir. That's why I asked...
> >
> > Oh, I am supposed to run make in tools/testing/radix-tree/?
> > What a surprise!
> >
> > Which is a pain when building in a separate output directory, as you
> > cannot just do "make -C tools/testing/radix-tree" there, but have to
> > type the full "make -C tools/testing/radix-tree O=..." (and optionally
> > ARCH=... and CROSS_COMPILE=...; oh wait, these are ignored :-( in the
> > source directory instead...
>
> I'll await your patch to link all this together. Please Cc the authors.
I gave it a try for kselftests a few years ago.
https://lore.kernel.org/all/20190114135144.26096-1-geert+renesas@glider.be
Unfortunately only one patch was applied...
> > > it is to get m68k to build, you should probably know how to read a
> > > makefile.
> >
> > Like all other kernel cross-compilation? Usually you don't even have
> > to know where your cross-compiler is living:
> >
> > make ARCH=m68k
>
> Ignoring that I had to make a config - which asked challenging
> questions...
make ARCH=m68k defconfig
> And ignoring the steps to get m68k compiler...
apt install gcc-m68k-linux-gnu?
> > > > When trying the above, and ignoring failures due to missing packages
> > > > on my host:
> > > > - there are several weird build errors,
> > > > - this doesn't play well with O=,
> > > > - lots of scary warnings when building for 32-bit,
> > > > - ...
> > > >
>
> In file included from ./include/linux/sched.h:12,
> from arch/m68k/kernel/asm-offsets.c:15:
> ./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’
> 7 | register struct task_struct *current __asm__("%a2");
Which compiler are you using?
> > > > At least the kunit tests build (and run[1] ;-) most of the time...
> > >
> > > Do they? How about you break something in xarray and then try to boot
> > > the kunit, or try to boot to load that module.
> >
> > If you break the kernel beyond the point of booting, you can indeed
> > not run any test modules...
>
> Which is extremely easy when you are changing code that runs so early in
> the boot.
>
> My code found a compiler issue because it's the first function that
> returns a boolean. This is stupid.
Sorry. I don't understand this comment.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
* Geert Uytterhoeven <geert@linux-m68k.org> [250130 09:25]:
> Hi Liam,
Hi Geert,
I'd like to say sorry for getting upset about this.
>
> On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> >
> > I'll await your patch to link all this together. Please Cc the authors.
>
> I gave it a try for kselftests a few years ago.
> https://lore.kernel.org/all/20190114135144.26096-1-geert+renesas@glider.be
> Unfortunately only one patch was applied...
It is difficult to integrate the test framework due to the nature of it
stubbing out a lot of the kernel code it uses.
This is also a strength as it can be used to test unlikely failure
scenarios that are difficult or impossible to recreate in kunit or a
running kernel - even with injections of failures.
It can also be used to isolate issues for recreating, which is very
valuable in larger, longer running issues.
I also use the userspace testing to test rcu using threads and I think
that would be even more challenging on a booted system.
>
> > > > it is to get m68k to build, you should probably know how to read a
> > > > makefile.
> > >
> > > Like all other kernel cross-compilation? Usually you don't even have
> > > to know where your cross-compiler is living:
> > >
> > > make ARCH=m68k
> >
> > Ignoring that I had to make a config - which asked challenging
> > questions...
>
> make ARCH=m68k defconfig
That also prompts, defoldconfig did not.
>
> > And ignoring the steps to get m68k compiler...
>
> apt install gcc-m68k-linux-gnu?
There are a few compilers, multilib or such? I've had issues with
getting all the archs working for cross compile on the same machine
(arm, arm64, riscv, m68k, ppc, ppc64, parisc).
>
> > > > > When trying the above, and ignoring failures due to missing packages
> > > > > on my host:
> > > > > - there are several weird build errors,
> > > > > - this doesn't play well with O=,
> > > > > - lots of scary warnings when building for 32-bit,
> > > > > - ...
> > > > >
> >
> > In file included from ./include/linux/sched.h:12,
> > from arch/m68k/kernel/asm-offsets.c:15:
> > ./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’
> > 7 | register struct task_struct *current __asm__("%a2");
>
> Which compiler are you using?
I've had a hard time getting m68k to boot in qemu because of the lack of
userspace. I use m68k for nommu testing, but have a hard time getting
the buildroot to work correctly to build what I need.
This was a grumpy, pre-coffee way of saying that some tasks are not
straight forward and are extremely difficult to make straight forward.
Sorry, I should not have made such rash comments. I respect you and
your work and appreciate the help you have given me in the past.
I would also like to thank you for your earlier statements. After
rereading them, I believe I misunderstood what you were saying. I've
been trying to make these tests a part of automatic testing somehow,
even getting them to run in userspace.
>
> > > > > At least the kunit tests build (and run[1] ;-) most of the time...
> > > >
> > > > Do they? How about you break something in xarray and then try to boot
> > > > the kunit, or try to boot to load that module.
> > >
> > > If you break the kernel beyond the point of booting, you can indeed
> > > not run any test modules...
> >
> > Which is extremely easy when you are changing code that runs so early in
> > the boot.
> >
> > My code found a compiler issue because it's the first function that
> > returns a boolean. This is stupid.
>
> Sorry. I don't understand this comment.
I had a bug a few years ago that turned out to be a clang compiler issue
with booleans. It turns out my code was the first function to return
a boolean and that wasn't being properly handled by the compiler (thanks
to mitigation of clearing registers with certain .config/compiler
flags).. it's not important.
More importantly, I think I get your point, you think that the testing
should be integrated and complain if it's broken - at least by bots. I
don't think this is practical in all cases, unfortunately.
Although I would like to strive for this - and I do by keeping any tests
I can as a kernel module while keeping the harder to recreate issues as
user space. I think we do a good job keeping testing up to date and
adding testcases as new issues are discovered.
Thanks,
Liam
Hi Liam,
On Thu, 30 Jan 2025 at 16:17, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [250130 09:25]:
> > On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > > > > it is to get m68k to build, you should probably know how to read a
> > > > > makefile.
> > > >
> > > > Like all other kernel cross-compilation? Usually you don't even have
> > > > to know where your cross-compiler is living:
> > > >
> > > > make ARCH=m68k
> > >
> > > Ignoring that I had to make a config - which asked challenging
> > > questions...
> >
> > make ARCH=m68k defconfig
>
> That also prompts, defoldconfig did not.
Hmm, using a defconfig should never ask for questions.
Perhaps this might happen if it has an option enabled that depends on
specific compiler support?
> > > And ignoring the steps to get m68k compiler...
> >
> > apt install gcc-m68k-linux-gnu?
>
> There are a few compilers, multilib or such? I've had issues with
> getting all the archs working for cross compile on the same machine
> (arm, arm64, riscv, m68k, ppc, ppc64, parisc).
I have installed all of the above (and more) from Ubuntu
(except for parisc, as Ubuntu does not have it), and more
from https://www.kernel.org/pub/tools/crosstool/.
All of them should work fine (for building kernels).
> > > > > > When trying the above, and ignoring failures due to missing packages
> > > > > > on my host:
> > > > > > - there are several weird build errors,
> > > > > > - this doesn't play well with O=,
> > > > > > - lots of scary warnings when building for 32-bit,
> > > > > > - ...
> > > > > >
> > >
> > > In file included from ./include/linux/sched.h:12,
> > > from arch/m68k/kernel/asm-offsets.c:15:
> > > ./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’
> > > 7 | register struct task_struct *current __asm__("%a2");
> >
> > Which compiler are you using?
>
> I've had a hard time getting m68k to boot in qemu because of the lack of
> userspace. I use m68k for nommu testing, but have a hard time getting
> the buildroot to work correctly to build what I need.
I only do m68k with MMU, and use Debian (ports) userland.
Perhaps https://landley.net/toybox/ might give you a nommu userland.
> More importantly, I think I get your point, you think that the testing
> should be integrated and complain if it's broken - at least by bots. I
> don't think this is practical in all cases, unfortunately.
Exactly:
- (cross)building kernel module tests is easy, and included in a
kernel build, so build failures are detected early.
- (cross)building the userland testing tools is cumbersome.
So there's an opportunity for improvement...
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Jan 29, 2025 at 5:26 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * Tamir Duberstein <tamird@gmail.com> [250129 16:29]:
> > On Wed, Jan 29, 2025 at 4:26 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > >
> > > * Sidhartha Kumar <sidhartha.kumar@oracle.com> [250129 16:02]:
> > > > + Liam, Matthew
> > >
> > > + linux-mm
> > >
> > > Thank you Sid.
> > >
> > > >
> > > > Hello,
> > > >
> > > > I believe this patch needs to be reverted for now as it breaks the
> > > > user-space build of /tools/testing/radix-tree with:
> > > >
> > > > In file included from xarray.c:11:
> > > > ../../../lib/test_xarray.c:9:10: fatal error: kunit/test.h: No such file
> > > > or directory
> > > > 9 | #include <kunit/test.h>
> > > > | ^~~~~~~~~~~~~~
> > > > compilation terminated.
> > > > make: *** [<builtin>: xarray.o] Error 1
> > > > make: *** Waiting for unfinished jobs....
> > > >
> > > > this then prevents the maple tree test suite from building.
> > >
> > > How are grammar corrections going to the right person (but not the
> > > mailing list) while an entire conversion to kunit is not [1]?
> >
> > Very simple: the tests are not properly included in MAINTAINERS. I
> > sent https://lore.kernel.org/all/20250129-xarray-test-maintainer-v1-1-482e31f30f47@gmail.com/
> > a few minutes ago for this reason.
>
> Fair enough, but from the patch:
>
> @@ -6,11 +6,10 @@
> * Author: Matthew Wilcox <willy@infradead.org>
> */
>
> -#include <linux/xarray.h>
> -#include <linux/module.h>
> +#include <kunit/test.h>
>
> ...
>
>
> -module_init(xarray_checks);
> -module_exit(xarray_exit);
> MODULE_AUTHOR("Matthew Wilcox <willy@infradead.org>");
> MODULE_DESCRIPTION("XArray API test module");
> MODULE_LICENSE("GPL");
>
> I don't get why the huge list of Cc's didn't include the author who is
> in the git commit signers:
> $ ./scripts/get_maintainer.pl --git lib/xarray.c
> Matthew Wilcox <willy@infradead.org> (supporter:XARRAY,commit_signer:1/3=33%,authored:1/3=33%,added_lines:19/52=37%,removed_lines:4/23=17%)
> Andrew Morton <akpm@linux-foundation.org> (supporter:LIBRARY CODE,commit_signer:3/3=100%)
I'm not sure what you're asking. I used `b4 prep --auto-to-cc`. It
doesn't know that test_xarray.c and xarray.c have the same maintainer.
> ...
>
> >
> > > Does the patch really need to drop the module testing too?
> > >
> > > What exactly is the point of converting one testing system to another
> > > besides disruption of actual work? Who asked for this? What is the
> > > point?
> >
> > All this is described in the commit message.
>
> The commit message says you like the output more and implies you like
> the command better.
>
> I've never used the kunit testing of xarray and have used the userspace
> testing instead, so I can't speak to the obscure invocation as both
> commands seem insanely long and obscure to me.
>
> >
> > > Is anyone doing work on the xarray running the kunit tests?
> >
> > I was doing work on xarray and I was running the kunit tests.
>
> ...
>
> You should look at the userspace testing (that this broke) as it has
> been really useful in certain scenarios.
>
> Thanks,
> Liam
For what it's worth the kunit invocation, while obscure, is
self-documenting. There's usage information that's reasonably
understandable embedded in the tool itself. I looked for the userspace
testing initially but failed to find
tools/testing/radix-tree/xarray.c. Even now, I'm not sure how I'm
meant to compile this.
Tamir
On Wed, Jan 29, 2025 at 05:33:06PM -0500, Tamir Duberstein wrote: > > $ ./scripts/get_maintainer.pl --git lib/xarray.c > > Matthew Wilcox <willy@infradead.org> (supporter:XARRAY,commit_signer:1/3=33%,authored:1/3=33%,added_lines:19/52=37%,removed_lines:4/23=17%) > > Andrew Morton <akpm@linux-foundation.org> (supporter:LIBRARY CODE,commit_signer:3/3=100%) > > I'm not sure what you're asking. I used `b4 prep --auto-to-cc`. It > doesn't know that test_xarray.c and xarray.c have the same maintainer. You need to use your brain. You can't just say "I used the tool". Tools are just tools. Sometimes they're wrong. My email address is listed as the Author: of test_xarray.c. You should have noticed that. > For what it's worth the kunit invocation, while obscure, is > self-documenting. There's usage information that's reasonably > understandable embedded in the tool itself. I looked for the userspace > testing initially but failed to find > tools/testing/radix-tree/xarray.c. Even now, I'm not sure how I'm > meant to compile this. kunit is useless. The test_xarray.c module is useless. If you break xarray, the kernel won't boot far enough to load any modules. You haven't thought about this AT ALL. cd tools/testing/radix-tree make Then you can run the tests, whichever ones make sense for you to run.
On Wed, Jan 29, 2025 at 6:02 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Wed, Jan 29, 2025 at 05:33:06PM -0500, Tamir Duberstein wrote: > > > $ ./scripts/get_maintainer.pl --git lib/xarray.c > > > Matthew Wilcox <willy@infradead.org> (supporter:XARRAY,commit_signer:1/3=33%,authored:1/3=33%,added_lines:19/52=37%,removed_lines:4/23=17%) > > > Andrew Morton <akpm@linux-foundation.org> (supporter:LIBRARY CODE,commit_signer:3/3=100%) > > > > I'm not sure what you're asking. I used `b4 prep --auto-to-cc`. It > > doesn't know that test_xarray.c and xarray.c have the same maintainer. > > You need to use your brain. You can't just say "I used the tool". > Tools are just tools. Sometimes they're wrong. My email address is > listed as the Author: of test_xarray.c. You should have noticed that. The whole point of tools is to liberate stupid humans' brains like mine from mundane tasks like working out who to email. The tool wasn't wrong; it did exactly what you told it to do in your MAINTAINERS entry. > > For what it's worth the kunit invocation, while obscure, is > > self-documenting. There's usage information that's reasonably > > understandable embedded in the tool itself. I looked for the userspace > > testing initially but failed to find > > tools/testing/radix-tree/xarray.c. Even now, I'm not sure how I'm > > meant to compile this. > > kunit is useless. The test_xarray.c module is useless. If you break > xarray, the kernel won't boot far enough to load any modules. You > haven't thought about this AT ALL. I don't understand what you're saying here. > cd tools/testing/radix-tree > make > > Then you can run the tests, whichever ones make sense for you to run. Thanks.
On Wed, Jan 29, 2025 at 06:08:22PM -0500, Tamir Duberstein wrote: > The whole point of tools is to liberate stupid humans' brains like > mine from mundane tasks like working out who to email. The tool wasn't > wrong; it did exactly what you told it to do in your MAINTAINERS > entry. Tools do get things wrong. So do humans. When you take your hands off the steering wheel and the car crashes, it's still your fault. > > > For what it's worth the kunit invocation, while obscure, is > > > self-documenting. There's usage information that's reasonably > > > understandable embedded in the tool itself. I looked for the userspace > > > testing initially but failed to find > > > tools/testing/radix-tree/xarray.c. Even now, I'm not sure how I'm > > > meant to compile this. > > > > kunit is useless. The test_xarray.c module is useless. If you break > > xarray, the kernel won't boot far enough to load any modules. You > > haven't thought about this AT ALL. > > I don't understand what you're saying here. Then I don't want to see any more patches from you until you do.
On Wed, Jan 29, 2025 at 6:11 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Wed, Jan 29, 2025 at 06:08:22PM -0500, Tamir Duberstein wrote: > > The whole point of tools is to liberate stupid humans' brains like > > mine from mundane tasks like working out who to email. The tool wasn't > > wrong; it did exactly what you told it to do in your MAINTAINERS > > entry. > > Tools do get things wrong. So do humans. When you take your hands off > the steering wheel and the car crashes, it's still your fault. Which one of us is driving in this analogy? > > > > For what it's worth the kunit invocation, while obscure, is > > > > self-documenting. There's usage information that's reasonably > > > > understandable embedded in the tool itself. I looked for the userspace > > > > testing initially but failed to find > > > > tools/testing/radix-tree/xarray.c. Even now, I'm not sure how I'm > > > > meant to compile this. > > > > > > kunit is useless. The test_xarray.c module is useless. If you break > > > xarray, the kernel won't boot far enough to load any modules. You > > > haven't thought about this AT ALL. > > > > I don't understand what you're saying here. > > Then I don't want to see any more patches from you until you do. Yes, I see now. But it's not quite true; the patch was itself motivated by the difficult output of the tests, so I did run this with kunit in a state that produced a failure. Your point is taken.
© 2016 - 2025 Red Hat, Inc.