Re: [PATCH v5 3/5] liveupdate: block session mutations during reboot

[Pasha Tatashin <pasha.tatashin@soleen.com>]

On 05-18 18:31, Pratyush Yadav wrote:
> On Mon, May 18 2026, Pasha Tatashin wrote:
> 
> > During the reboot() syscall, user processes may still be running
> > concurrently and attempting to mutate sessions (e.g., creating,
> > retrieving, or releasing sessions). To prevent this, introduce
> > luo_session_serialize_rwsem to synchronize mutations with the
> > serialization process.
> >
> > All session mutation operations (create, retrieve, release, ioctl) take
> > the read lock. The serialization process (luo_session_serialize) takes
> > the write lock and holds it indefinitely on success. This effectively
> > freezes the LUO session subsystem during the transition to the new
> > kernel. If serialization fails, the lock is released to allow recovery.
> 
> Good idea I think.

Hi Pratyush,

> 
> But, do we need a new mutex? Can't we use luo_session_header->rwsem?
> Session creation and release take the header rwsem at one point anyway,
> so perhaps we can just reuse that?

The sh->rwsem is for protecting the the session list. We only take it as 
a writer when modifying the list (insert/remove) and as a reader when 
traversing it. Also, we drop sh->rwsem as soon as we've acquired the 
per-session mutex to allow other list operations to proceed while a 
session is being modified.

Because of this, many session mutation operations (specifically ioctl 
calls) don't touch sh->rwsem at all—they jump straight to the  session 
state via the file's private_data. To use sh->rwsem to block
these mutations, we would be forced to add down_read(&sh->rwsem) to 
every ioctl path. This would be a layering violation, coupling list 
management to per-session data mutations, and would introduce a global
bottleneck for operations that are otherwise independent.

The only other way to prevent mutations without a new global lock would 
be for the reboot process to acquire every individual session mutex. 
However, since LUO_SESSION_MAX can be large, this would exceed lockdep's 
maximum lock tracking limit and trigger failures. The 
luo_session_serialize_rwsem provides a dedicated signal to freeze the 
entire subsystem without messing with the existing fine-grained locking 
logic.

> 
> Also, do we need to block incoming sessions? They won't participate in
> serialization, so perhaps we can leave those alone, and all the outgoing
> sessions get protected by the outgoing session header rwsem?

Incoming sessions don't participate in serialization, but blocking them 
makes the code more robust. This provides a level of future proofing if 
new ioctls or operations are added later, we won't accidentally miss a 
path that should have been frozen during reboot. It's safer to treat the 
subsystem as a single unit that freezes entirely once the transition 
begins.

Pasha