In FC42, when I run "./luo_multi_session"
# ./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.
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 <[email protected]> wrote:
On Sun, Nov 09 2025, Zhu Yanjun wrote:
在 2025/11/8 10:13, Pasha Tatashin 写道:
On Fri, Nov 7, 2025 at 6:36 PM Yanjun.Zhu <[email protected]> wrote:
On 11/7/25 4:02 AM, Pasha Tatashin wrote:
On Fri, Nov 7, 2025 at 7:00 AM Pasha Tatashin <[email protected]> wrote:
Hi, Pasha
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?
It is an optional config and can still be enabled if the live update
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
Forgot to add link to WIP LUOv5:
[1] https://github.com/soleen/linux/tree/luo/v5rc04
Thanks a lot. I’ve carefully read this commit:
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?
Currently the test performs in-kernel tests for FLB data, it creates a
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:
Hi, Pasha
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.
You need to add liveupdate=1 to your kernel cmdline to enable LUO and
get /dev/liveupdate.
+1, kernel parameters require: kho=1 liveupdate=1
Pasha, your LUO series doesn't add the liveupdate parameter to
kernel-parameters.txt. I think it should be done in the next version to
this parameter is discoverable.
Yeah, that is missing, I will update that in a standalone patch, or in
a next version.
Thanks,
Pasha
--
Best Regards,
Yanjun.Zhu
