Re: [RFC] liveupdate: prevent double preservation
From: Pasha Tatashin
Date: Fri Mar 20 2026 - 10:28:01 EST
On Fri, Mar 20, 2026 at 9:47 AM Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxx>
> > ---
> >
> > 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@xxxxxxx>
>
> Just one nit below:
>
> > [1] https://lore.kernel.org/all/20260129212510.967611-1-dmatlack@xxxxxxxxxx
> > [2] https://lore.kernel.org/all/20260203220948.2176157-1-skhawaja@xxxxxxxxxx
> >
> > @@ -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@xxxxxxxx>
> SUSE Labs, CR