STRUCT LUO_FILE(9)

💅 struct luo_file — NAME 💅

okay bestie, welcome to the struct luo_file(9) glow-up ✨ this is the kernel-API page for struct luo_file, and it's literally just: Represents a single preserved file instance. That's it, that's the vibe 🎀

---

🌸 SYNOPSIS 🌸

struct luo_file {
    struct liveupdate_file_handler *fh;
    struct file *file;
    u64 serialized_data;
    void *private_data;
    int retrieve_status;
    struct mutex mutex;
    struct list_head list;
    u64 token;
 };

no cap, that's the whole shape of it 🦋

---

👑 Members 👑

• fh — pointer to the struct liveupdate_file_handler that manages this type of file. like, the handler that owns this whole situation 💁‍♀️
• file — pointer to the kernel's struct file that's being preserved. ⚠️ it's NULL in the new kernel until the file is successfully retrieved — so don't go dereferencing it early, bestie 😭
• serialized_data — the opaque u64 handle to the serialized state of the file. this handle gets passed back to the handler's .freeze, .retrieve, and .finish callbacks, so the handler can track and update its serialized state across phases 🔥
• private_data — pointer to the private data for the file, used to hold runtime state that is not preserved. it's set by the handler's .preserve callback, and it must be freed in the handler's .unpreserve callback 🫶 (yes, that's you, free it)
• retrieve_status — status code telling you whether a user/kernel in the new kernel has successfully called retrieve on this file. it's giving gatekeeper: it prevents multiple retrieval attempts 💅 so the values are:
  • 0 → a retrieve has not been attempted
  • a positive value → the retrieve was successful ✨
  • a negative value → the retrieve failed, and that value is the error code of the call 💀
• mutex — a mutex that protects the fields of this specific instance (e.g., retrieved, file), keeping stuff like retrieving or finishing a file atomic. iconic locking behaviour, we stan 🔒
• list — the list_head that links this instance into its parent file_set's list of preserved files 🌈
• token — the user-provided unique token used to identify this file. iykyk 🎀

---

🧚 Description 🧚

this structure is the core in-kernel representation of a single file being managed through a live update. main character energy fr fr 👑

an instance gets created by luo_preserve_file, and it links a 'struct file' to its corresponding handler, a user-provided token, and the serialized state handle returned by the handler's .preserve operation. three things, one struct, slay 🫶

these instances are tracked in a per-file_set list. the serialized_data field — which holds a handle to the file's serialized state — may be updated during the .freeze callback before being serialized for the next kernel. then after reboot, these structures get recreated by luo_file_deserialize 💫 and are finally cleaned up by luo_file_finish. full lifecycle, no loose ends ✨

---

👀 SEE ALSO 👀

• Kernel file ./kernel/liveupdate/luo_file.c
• LUO File Descriptors(9)
• luo_preserve_file(9)
• luo_file_unpreserve_files(9)
• luo_file_freeze(9)
• luo_file_unfreeze(9)
• luo_retrieve_file(9)
• luo_file_finish(9)
• luo_file_deserialize(9)
• liveupdate_register_file_handler(9)
• liveupdate_unregister_file_handler(9)

go read them, bestie, they're all linked in the group chat 🦋

---

and that's the page!! 🎀💖 source/version: ./kernel/liveupdate · dated October 2026 · manual struct luo_file(9) — mwah, periodt 💅🫶