Re: [PATCH v9 1/9] kho: make debugfs interface optional
From: Yanjun.Zhu
Date: Wed Nov 12 2025 - 21:11:54 EST
On 11/12/25 5:41 PM, Yanjun.Zhu wrote:
On 11/11/25 7:26 AM, Pasha Tatashin wrote:
On Mon, Nov 10, 2025 at 11:11 PM Zhu Yanjun <yanjun.zhu@xxxxxxxxx> wrote:In FC42, when I run "./luo_multi_session"Looks like mountroot fails, are you passing the same kernel parameters
# ./luo_multi_session
# [STAGE 1] Starting pre-kexec setup for multi-session test...
# [STAGE 1] Creating state file for next stage (2)...
# [STAGE 1] Creating empty sessions 'multi-test-empty-1' and
'multi-test-empty-2'...
# [STAGE 1] Creating session 'multi-test-files-1' with one memfd...
# [STAGE 1] Creating session 'multi-test-files-2' with two memfds...
# [STAGE 1] Executing kexec...
Then the system hang. And via virt-viewer, a calltrace will appear.
as the during cold boot?
i.e. kexec -l -s --reuse-cmdline --initrd=[initramfs] [kernel]
Thanks a lot. It can work now. The logs are as below:
"
# [STAGE 2] Starting post-kexec verification...
# [STAGE 2] Retrieving all sessions...
# [STAGE 2] Verifying contents of session 'multi-test-files-1'...
# [STAGE 2] Verifying contents of session 'multi-test-files-2'...
# [STAGE 2] Test data verified successfully.
# [STAGE 2] Finalizing all test sessions...
# [STAGE 2] Finalizing state session...
#
--- MULTI-SESSION KEXEC TEST PASSED ---
"
Yanjun.Zhu
Hi, Pasha
In my tests, I found that luo_kexec_simple and luo_multi_session currently depend on the glibc-static library.
If this library is not installed, build errors occur.
By making the following changes, luo_kexec_simple and luo_multi_session would no longer depend on glibc-static, reducing external library dependencies.
I am not sure whether you agree with these proposed changes.
diff --git a/tools/testing/selftests/liveupdate/Makefile b/tools/testing/selftests/liveupdate/Makefile
index 6ee6efeec62d..b226b9976150 100644
--- a/tools/testing/selftests/liveupdate/Makefile
+++ b/tools/testing/selftests/liveupdate/Makefile
@@ -3,7 +3,6 @@
KHDR_INCLUDES ?= -I../../../../usr/include
CFLAGS += -Wall -O2 -Wno-unused-function
CFLAGS += $(KHDR_INCLUDES)
-LDFLAGS += -static
OUTPUT ?= .
# --- Test Configuration (Edit this section when adding new tests) ---
Yanjun.Zhu
Pasha
The call trace is in the attachment.
Yanjun.Zhu
在 2025/11/10 7:26, Pasha Tatashin 写道:
On Mon, Nov 10, 2025 at 8:16 AM Pratyush Yadav <pratyush@xxxxxxxxxx> wrote:--On Sun, Nov 09 2025, Zhu Yanjun wrote:+1, kernel parameters require: kho=1 liveupdate=1
在 2025/11/8 10:13, Pasha Tatashin 写道:You need to add liveupdate=1 to your kernel cmdline to enable LUO and
On Fri, Nov 7, 2025 at 6:36 PM Yanjun.Zhu <yanjun.zhu@xxxxxxxxx> wrote:Hi, PashaOn 11/7/25 4:02 AM, Pasha Tatashin wrote:Currently the test performs in-kernel tests for FLB data, it creates a
On Fri, Nov 7, 2025 at 7:00 AM Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> wrote:Thanks a lot. I’ve carefully read this commit:Forgot to add link to WIP LUOv5:Hi, PashaIt is an optional config and can still be enabled if the live update
In our previous discussion, we talked about counting the number of times
the kernel is rebooted via kexec. At that time, you suggested adding a
variable in debugfs to keep track of this count.
However, since debugfs is now optional, where would be an appropriate
place to store this variable?
reboot number value needs to be accessed through debugfs. However,
given that debugfs does not guarantee a stable interface, tooling
should not be built to require these interfaces.
In the WIP LUO [1] I have, I pr_info() the live update number during
boot and also store it in the incoming LUO FDT tree, which can also be
accessed through this optional debugfs interface.
The pr_info message appears like this during boot:
[ 0.000000] luo: Retrieved live update data, liveupdate number: 17
Pasha
[1] https://github.com/soleen/linux/tree/luo/v5rc04
https://github.com/soleen/linux/commit/60205b9a95c319dc9965f119303a1d83f0ff08fa.
To be honest, I’d like to run some tests with who/luo, including the
selftest for kho/luo. Could you please share the steps with me?
If the testing steps have already been documented somewhere, could you
please share the link?
number of FLB for every registered LUO file-handler, which at the
moment is only memfd.
It works together with any of the kexec based live update tests. In
v5, I introduce two tests:
luo_kexec_simple
luo_multi_session
For example, with luo_multi_session:
I enabled "CONFIG_LIVEUPDATE=y"
# ./luo_multi_session
1..0 # SKIP Failed to open /dev/liveupdate. Is the luo module loaded?
# ls /dev/liveupdate
ls: cannot access '/dev/liveupdate': No such file or directory
# grep "LIVEUPDATE" -inrHI /boot/config-`uname -r`
/boot/config-next-20251107-luo+:349:CONFIG_LIVEUPDATE=y
/boot/config-next-20251107-luo+:11985:CONFIG_LIVEUPDATE_TEST=y
I made tests on FC42. But /dev/liveupdate is missing.
get /dev/liveupdate.
Pasha, your LUO series doesn't add the liveupdate parameter toYeah, that is missing, I will update that in a standalone patch, or in
kernel-parameters.txt. I think it should be done in the next version to
this parameter is discoverable.
a next version.
Thanks,
Pasha
Best Regards,
Yanjun.Zhu