On Tue, Apr 28 2026, Pasha Tatashin wrote: > On 04-04 10:24, Pratyush Yadav wrote: >> From: "Pratyush Yadav (Google)" <[email protected]> >> >> Hi, >> >> This series adds some tests for memfd preservation across a live update. >> Currently memfd is only tested indirectly via luo_kexec_simple or >> luo_multi_session. Add a dedicated test suite for it. >> >> Patches 1 and 2 are preparatory, adding base framework and helpers, and >> the other patches each add a test. Some of the code is taken from the >> libluo patches [0] I sent a while ago. >> >> [0] >> https://lore.kernel.org/linux-mm/[email protected]/ > > Here are few observations that I noticed when I tried to run your tests: > > 1. The '-h' tells you nothing about --stage argument: > > root@liveupdate-vm:~/liveupdate# ./luo_memfd -h > Usage: ./luo_memfd [-h|-l|-d] [-t|-T|-v|-V|-f|-F|-r name] > -h print help > -l list all tests > -d enable debug prints > > -t name include test > -T name exclude test > -v name include variant > -V name exclude variant > -f name include fixture > -F name exclude fixture > -r name run specified test > ...
Yeah, unfortunately that is a side effect of using test_harness_run(), which does not know anything about the options specific to our test. > > 2. '-l' does not work after you run stage1, do you keep /dev/liveupdate > open? That is not needed, we only need to keep session open. Oh yeah, I keep forgetting that is no longer needed. The main process closes the FD but the forked daemons hold a reference. I can clean that up via a fixture. > > root@liveupdate-vm:~/liveupdate# ./luo_memfd -l > 1..0 # SKIP Failed to open /dev/liveupdate (Device or resource busy) device. > Is LUO enabled? > > 3. Stage 1 has proper [STAGE 1] prefix, but no [STAGE 2] prefix for Because stage 2 has no prints, all the prints are coming from the selftest harness. Those same lines are also not prefixed in stage 1. If you'd like, I can add a print beforehand that shows which stage is running. Other than that, I don't see what else we can do. I don't want to modify the selftest harness. > stage 2: > # Starting 4 tests from 1 test cases. > # RUN global.memfd_data ... > # [STAGE 1] Forking persistent child to hold sessions... > # [STAGE 1] Child PID: 245. Resources are pinned. > # [STAGE 1] You may now perform kexec reboot. > # OK global.memfd_data > ok 1 global.memfd_data > # RUN global.zero_memfd ... > # [STAGE 1] Forking persistent child to hold sessions... > # [STAGE 1] Child PID: 247. Resources are pinned. > # [STAGE 1] You may now perform kexec reboot. > # OK global.zero_memfd > ok 2 global.zero_memfd > # RUN global.preserved_ops ... > # OK global.preserved_ops > ok 3 global.preserved_ops > # RUN global.fallocate_memfd ... > # [STAGE 1] Forking persistent child to hold sessions... > # [STAGE 1] Child PID: 250. Resources are pinned. > # [STAGE 1] You may now perform kexec reboot. > # OK global.fallocate_memfd > ok 4 global.fallocate_memfd > # PASSED: 4 / 4 tests passed. > # Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0 > > ./do_kexec > > root@liveupdate-vm:~/liveupdate# ./luo_memfd > TAP version 13 > 1..4 > # Starting 4 tests from 1 test cases. > # RUN global.memfd_data ... > # OK global.memfd_data > ok 1 global.memfd_data > # RUN global.zero_memfd ... > # OK global.zero_memfd > ok 2 global.zero_memfd > # RUN global.preserved_ops ... > # SKIP test only expected to run on stage 1 > # OK global.preserved_ops > ok 3 global.preserved_ops # SKIP test only expected to run on stage 1 > # RUN global.fallocate_memfd ... > # OK global.fallocate_memfd > ok 4 global.fallocate_memfd > # PASSED: 4 / 4 tests passed. > # 1 skipped test(s) detected. Consider enabling relevant config options to > improve coverage. > # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:1 error:0 > > 4. I also do not like that we now have duplicated stage parsing code in > luo_test(), perhaps we should add our own test_harness_run() variant > that depends on stage, and use it in both current tests, and the new > memfd tests. Sounds good in principle, but unfortunately ends up duplicating a lot of logic in test_harness_run() that is not a good idea IMO. We should work with the harness not fork off into our own. I suppose we can refactor some of the logic there to split into functions that we can then use in our luo_test_harness_run(), but keeping the option parsing logic in sync is going to be difficult. And for the duplicated logic, I agree. I thought about cleaning it up but was feeling lazy... Well now that you have called it out let me see what I can do. [...] -- Regards, Pratyush Yadav
