On Thu, 16 Jul 2026 at 16:23, Pratyush Yadav <[email protected]> wrote: > > On Wed, Jul 15 2026, Jason Gunthorpe wrote: > > > 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. > > AFAIK I doesn't do so today. You can either create FDs and save them via > FDStore, and systemd will put them in its global session, or you grab a > session directly from /dev/liveupdate and save the session via FDStore. > Maybe in the future it will add the capability to vend out sessions > through dbus as well, but at least today it doesn't do so.
I've added it after Pasha asked for it, will be in the next release: https://www.freedesktop.org/software/systemd/man/devel/systemd.service.html#LUOSession=
