Re: [RFC] liveupdate: prevent double preservation

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

On Fri, Mar 20, 2026 at 9:47 AM Jan Kara <jack@suse.cz> wrote:
>
> On Mon 16-03-26 22:38:34, Pasha Tatashin wrote:
> > Currently, LUO does not prevent the same file from being preserved twice
> > across different active sessions.
> >
> > Add a new i_state flag I_LUO_PRESERVED and update luo_preserve_file()
> > to check and set this flag when a file is preserved, and clear it in
> > luo_file_unpreserve_files() when it is released. This ensures that the
> > same file (inode) cannot be preserved by multiple sessions. If another
> > session attempts to preserve an already preserved file, it will now
> > fail with -EBUSY.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> >
> > Background:
> > Because LUO preserves files of absolutely different types: memfd, and
> > upcoming  vfiofd [1], iommufd [2], guestmefd (and possible kvmfd/cpufd).
> > There is no common private data or guarantee on how to prevent that the
> > same file is not preserved twice beside using inode or some slower and
> > expensive method like hashtables.
>
> OK, I guess since this is a single bit, we can live with that although it
> seems a bit wrong that LUO needs this in generic struct inode. But all
> other "cleaner" variants I could think of were just an overkill. So feel
> free to add:
>
> Acked-by: Jan Kara <jack@suse.cz>
>
> Just one nit below:
>
> > [1] https://lore.kernel.org/all/20260129212510.967611-1-dmatlack@google.com
> > [2] https://lore.kernel.org/all/20260203220948.2176157-1-skhawaja@google.com
> >
> > @@ -744,7 +746,8 @@ enum inode_state_flags_enum {
> >       I_CREATING              = (1U << 15),
> >       I_DONTCACHE             = (1U << 16),
> >       I_SYNC_QUEUED           = (1U << 17),
> > -     I_PINNING_NETFS_WB      = (1U << 18)
> > +     I_PINNING_NETFS_WB      = (1U << 18),
> > +     I_LUO_PRESERVED         = (1U << 19)
>
> Add comma at the end of line here please so that we don't have to modify
> the last line again.

Will do.

Thank you,
Pasha

>
>                                                                 Honza
>
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR