From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: pasha.tatashin@soleen.com, rppt@kernel.org, pratyush@kernel.org,
linux-kernel@vger.kernel.org, dmatlack@google.com,
akpm@linux-foundation.org, linux-mm@kvack.org
Subject: [PATCH 0/6] liveupdate: Fix module unloading and unregister API
Date: Mon, 16 Mar 2026 22:50:43 -0400 [thread overview]
Message-ID: <20260317025049.494931-1-pasha.tatashin@soleen.com> (raw)
This patch series addresses an issue with how LUO handles module
reference counting and unregistration during a module unload (e.g.,
via rmmod).
Currently, modules that register live update file handlers are pinned
for the entire duration they are registered. This prevents the modules
from being unloaded gracefully, even when no live update session is in
progress.
Furthermore, if a module is forcefully unloaded, the unregistration
functions return an error (e.g. -EBUSY) if a session is active, which
is ignored by the kernel's module unload path, leaving dangling
pointers in the LUO global lists.
As pointed out by Jason Gunthorpe and Alex Williamson during the review
of the VFIO PCI live update patches [1]:
> "destroy" functions that fail are evil. :)
> IMHO blow up the kernel or something in the core code, you can't stop
> module unloading once it starts so it is pointless to propagate this
To resolve these issues, this series introduces the following changes:
1. Adds read-write semaphores (luo_file_handler_lock, luo_flb_lock, and
a per-handler flb_lock) to protect the registration lists. This allows
highly scalable concurrent access for file preservation without
blocking, while still preventing traversal races during module unload.
2. Defers module reference counting (try_module_get / module_put)
so that modules are only pinned when their handlers or FLBs are
actively used in a live update session. This allows the core kernel
module code to correctly reject an unload attempt (-EWOULDBLOCK)
only when a session is actively running.
3. Changes the unregistration functions to return void instead of
an error code. If they fail to unregister due to dangling references,
they print a warning instead of aborting, aligning with standard
kernel destroy/unregister semantics.
4. Removes the global luo_session_quiesce() mechanism. Now that module
references properly handle the usage of file handlers and FLBs
during active sessions, we can safely remove the quiesce/resume logic.
[1] https://lore.kernel.org/all/20260303210733.GG972761@nvidia.com
Pasha Tatashin (6):
liveupdate: Protect file handler list with rwsem
liveupdate: Protect FLB lists with rwsem
liveupdate: Defer file handler module refcounting to active sessions
liveupdate: Defer FLB module refcounting to active sessions
liveupdate: Make unregister functions return void
liveupdate: Remove luo_session_quiesce()
include/linux/liveupdate.h | 16 +++--
kernel/liveupdate/luo_file.c | 118 ++++++++++++++-----------------
kernel/liveupdate/luo_flb.c | 108 ++++++++++++----------------
kernel/liveupdate/luo_internal.h | 2 -
kernel/liveupdate/luo_session.c | 44 ------------
lib/tests/liveupdate.c | 8 +--
6 files changed, 113 insertions(+), 183 deletions(-)
--
2.53.0.851.ga537e3e6e9-goog
next reply other threads:[~2026-03-17 2:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 2:50 Pasha Tatashin [this message]
2026-03-17 2:50 ` [PATCH 1/6] liveupdate: Protect file handler list with rwsem Pasha Tatashin
2026-03-17 2:50 ` [PATCH 2/6] liveupdate: Protect FLB lists " Pasha Tatashin
2026-03-17 2:50 ` [PATCH 3/6] liveupdate: Defer file handler module refcounting to active sessions Pasha Tatashin
2026-03-17 16:38 ` David Matlack
2026-03-17 18:32 ` Pasha Tatashin
2026-03-17 2:50 ` [PATCH 4/6] liveupdate: Defer FLB " Pasha Tatashin
2026-03-17 2:50 ` [PATCH 5/6] liveupdate: Make unregister functions return void Pasha Tatashin
2026-03-17 8:58 ` kernel test robot
2026-03-17 10:10 ` kernel test robot
2026-03-17 13:03 ` Pasha Tatashin
2026-03-17 2:50 ` [PATCH 6/6] liveupdate: Remove luo_session_quiesce() Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260317025049.494931-1-pasha.tatashin@soleen.com \
--to=pasha.tatashin@soleen.com \
--cc=akpm@linux-foundation.org \
--cc=dmatlack@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox