[PATCH 0/2] ubifs: add KUnit tests for scan and key helpers

lichen.wang wanglichen9110 at gmail.com
Thu Sep 10 18:23:09 PDT 2026


This series adds KUnit tests for fs/ubifs/scan.c and for the helpers in
fs/ubifs/key.h, so that the node parsing code can be validated offline
without an MTD device, a UBI volume or a development board.

Baseline:

  commit df2908090cda368b01ff43709f51890076c56157 ("Linux 7.3-rc2")
  git describe --always of that commit: v7.3-rc2
  (the describe string is that of the base commit itself; the patch
  commits sit on top of it, so a describe run at their tip reports
  v7.3-rc2-2-gaf7a59658 instead)

Motivation:

UBIFS has no test coverage for its on-flash parsing code: checking a
change to scan.c or key.h currently means bringing up a real NAND
device, a UBI volume and a board. KUnit makes the same checks run in a
plain QEMU boot within seconds, and it is the established in-tree
framework for this kind of unit testing, so the tests are reusable by
anyone touching this code.

Approach:

 - The tests are compiled into the ubifs module itself (ubifs-y) so
   that they can call the non-exported ubifs_scan_a_node(),
   ubifs_check_node(), ubifs_add_snod() and ubifs_end_scan() directly.
   No EXPORT_SYMBOL() is added to production code.
 - kunit_helpers.h builds a minimal fake struct ubifs_info with
   kunit_kzalloc(); only the fields read by the tested paths are
   initialised. The node length ranges mirror init_constants_early()
   in super.c, because a zeroed range means "fixed length" for
   ubifs_check_node() and would make the length checks pass for the
   wrong reason.
 - The node constructor fills the common header and payload first and
   computes the CRC last with the kernel crc32(), over exactly the
   bytes that ubifs_check_node() checksums.

Testing:

The whole suite runs with a single command:

  ./tools/testing/kunit/kunit.py run --arch=x86_64 --timeout=300 'ubifs*'

Two consecutive runs of the final tree reported 5 suites and 80 cases,
all passing:

  Testing complete. Ran 80 tests: passed: 80

with zero "not ok" lines in the KTAP output. The archived logs are
reports/round-1.md, reports/round-2.md, reports/ktap-20260910-220005.txt
and reports/ktap-20260910-220802.txt; they live in the project tree
only and are deliberately not part of this series.

The fake ubifs_info environment was additionally checked against the
real stack: a nandsim smoke test booted the same kernel over a complete
MTD -> UBI -> UBIFS stack, attached mtd0, created and mounted the
volume and wrote and read back a file successfully (SMOKE: PASS). The
report is reports/smoke.md and the raw serial log is
reports/smoke-qemu.log.

Known limitations:

 - ubifs_scan() and ubifs_start_scan() are not covered: they read from
   a real UBI volume through ubi_leb_read() and are exercised by the
   nandsim smoke test instead.
 - The tests build nodes in memory, so they cannot catch bugs in the
   on-media layout itself; they only pin down the behaviour of the
   parsing code for the layouts that UBIFS currently writes.

Notes:

checkpatch.pl --strict reports 0 errors for both patches. Each patch
also carries the generic "added, moved or deleted file(s), does
MAINTAINERS need updating?" warning; that reminder is emitted for every
patch that adds a file, and the new files live under fs/ubifs/, which
is already covered by the "UBI FILE SYSTEM (UBIFS)" entry in
MAINTAINERS ("F: fs/ubifs/"), so no MAINTAINERS change is needed.

Signed-off-by: lichen.wang <wanglichen9110 at gmail.com>

lichen.wang (2):
  ubifs: add KUnit test scaffolding for scan.c
  ubifs: add KUnit tests for key helpers

 fs/ubifs/Kconfig               |  16 +
 fs/ubifs/Makefile              |   1 +
 fs/ubifs/tests/key_kunit.c     | 555 +++++++++++++++++++
 fs/ubifs/tests/kunit_helpers.h | 222 ++++++++
 fs/ubifs/tests/scan_kunit.c    | 980 +++++++++++++++++++++++++++++++++
 5 files changed, 1774 insertions(+)
 create mode 100644 fs/ubifs/tests/key_kunit.c
 create mode 100644 fs/ubifs/tests/kunit_helpers.h
 create mode 100644 fs/ubifs/tests/scan_kunit.c

--
2.43.0





More information about the linux-mtd mailing list