On Mon, May 26 2025, Mike Rapoport wrote: > On Thu, May 15, 2025 at 06:23:12PM +0000, Pasha Tatashin wrote: >> Introduce the framework within LUO to support preserving specific types >> of file descriptors across a live update transition. This allows >> stateful FDs (like memfds or vfio FDs used by VMs) to be recreated in >> the new kernel. >> >> Note: The core logic for iterating through the luo_files_list and >> invoking the handler callbacks (prepare, freeze, cancel, finish) >> within luo_do_files_*_calls, as well as managing the u64 data >> persistence via the FDT for individual files, is currently implemented >> as stubs in this patch. This patch sets up the registration, FDT layout, >> and retrieval framework. >> >> Signed-off-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> >> --- [...] >> diff --git a/drivers/misc/liveupdate/luo_core.c b/drivers/misc/liveupdate/luo_core.c >> index 417e7f6bf36c..ab1d76221fe2 100644 >> --- a/drivers/misc/liveupdate/luo_core.c >> +++ b/drivers/misc/liveupdate/luo_core.c >> @@ -110,6 +110,10 @@ static int luo_fdt_setup(struct kho_serialization *ser) >> if (ret) >> goto exit_free; >> >> + ret = luo_files_fdt_setup(fdt_out); >> + if (ret) >> + goto exit_free; >> + >> ret = luo_subsystems_fdt_setup(fdt_out); >> if (ret) >> goto exit_free; > > The duplication of files and subsystems does not look nice here and below. > Can't we make files to be a subsystem? +1 It would also give subsystems a user. [...] >> diff --git a/drivers/misc/liveupdate/luo_files.c b/drivers/misc/liveupdate/luo_files.c >> new file mode 100644 >> index 000000000000..953fc40db3d7 >> --- /dev/null >> +++ b/drivers/misc/liveupdate/luo_files.c >> @@ -0,0 +1,563 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> + >> +/* >> + * Copyright (c) 2025, Google LLC. >> + * Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> >> + */ >> + >> +/** >> + * DOC: LUO file descriptors >> + * >> + * LUO provides the infrastructure necessary to preserve >> + * specific types of stateful file descriptors across a kernel live >> + * update transition. The primary goal is to allow workloads, such as virtual >> + * machines using vfio, memfd, or iommufd to retain access to their essential >> + * resources without interruption after the underlying kernel is updated. >> + * >> + * The framework operates based on handler registration and instance tracking: >> + * >> + * 1. Handler Registration: Kernel modules responsible for specific file >> + * types (e.g., memfd, vfio) register a &struct liveupdate_filesystem >> + * handler. This handler contains callbacks (&liveupdate_filesystem.prepare, >> + * &liveupdate_filesystem.freeze, &liveupdate_filesystem.finish, etc.) >> + * and a unique 'compatible' string identifying the file type. >> + * Registration occurs via liveupdate_register_filesystem(). > > I wouldn't use filesystem here, as the obvious users are not really > filesystems. Maybe liveupdate_register_file_ops? +1 [...] -- Regards, Pratyush Yadav
