On Wed, Jul 15, 2026 at 03:50:33PM +0200, Pratyush Yadav wrote: > Hi David, > > On Tue, Jul 14 2026, David Matlack wrote: > > > Remove the single-opener restriction for /dev/liveupdate by removing the > > atomic in_use tracking and the exclusive open check in luo_open() that > > returned -EBUSY. Protect luo_session_deserialize() with a mutex guard so > > that concurrent open attempts by multiple processes safely executes > > deserialization only once. Update liveupdate selftest to verify that > > multiple concurrent openers succeed. > > > > LUO does not inherently require a single opener. There is some > > documentation about it simplifying state management, but the only thing > > it actually protects is the session deserialization during first open, > > which can be easily handled with a mutex. > > > > Relaxing the single-opener requirement avoids the kernel forcing a > > design pattern on userspace that it itself does not require, e.g. > > allowing multiple userspace processes to create and manage sessions. > > Agreed. When the kernel had a global state machine in the early versions > of LUO, this might have been more relevant. With sessions, even if we > later add a state machine, it likely will be per-session instead of > being global. So I think letting userspace open /dev/liveupdate multiple > times makes a lot of sense. > > Also, today's systemd only supports preserving individual files, and > does not hand out sessions. To get sessions, userspace must open > /dev/liveupdate and create a session. This opens up room for one bad > process to block every other process from creating sessions. It also > imposes a need for userspace to add a polling/retry logic for getting > sessions and serializes their execution around this point.
Shouldn't systemd open and own /dev/liveupdate? That was at least what I originally expected here, you'd talk to it and get a session FD through dbus. Moving to multi-opening /dev/liveupdate and removing visibility of what sessions are open from systemd is a different model Not saying this patch is wrong or anything, but that I don't really understand what kind of model you are going for now. Jason
