Re: [PATCH v2 3/8] liveupdate: Remove file handler module refcounting

[David Matlack]

On Tue, Mar 24, 2026 at 7:49 PM Pasha Tatashin
<pasha.tatashin@xxxxxxxxxx> wrote:
>
> On Tue, Mar 24, 2026 at 5:24 PM David Matlack <dmatlack@xxxxxxxxxx> wrote:
> >
> > On Wed, Mar 18, 2026 at 7:17 AM Pasha Tatashin
> > <pasha.tatashin@xxxxxxxxxx> wrote:
> > >
> > > File handlers do not need to pin modules indefinitely or during active
> > > live update sessions. The VFS 'struct file' pins the file handler's module
> > > via f_op->owner during active sessions, making dynamic reference counting
> > > unnecessary for handlers.
> > >
> > > When a file is preserved, the live update core obtains a 'struct file'
> > > via fdget(). As long as the file is kept open within the live update
> > > session, the module is pinned by the VFS and cannot be unloaded.
> >
> > After invoking the file handler's retrieve(), LUO should probably
> > check that the created file's owner matches the file handler's owner,
> > since this scheme relies on that being true.
> >
> > If there is a mismatch, LUO can put the file that was just created,
> > log a warning, and return an error up to the user.
>
> Is there a reason why taking a file handler module reference is
> problematic for vfio or iommu? Could we take it while files are
> present in incoming or outgoing sessions? Overall, it is because it
> cover corener cases such as if the file struct owner is the same as
> LUO file handler and also this approach covers the deserialziation
> side nicely.

I see no problem with LUO taking a reference to the file handle module
owner while a file associated with it is preserved in an incoming or
outgoing session.

And I realized that VFIO can have different owners for the file (vfio
module) and file handler (vfio-pci module), as it is currently
implemented. It should still be safe to rely on the file reference,
but explicitly taking a reference to the file handler would be simpler
to reason about. So I am ok with going back to what you had in v1 [1].

[1] https://lore.kernel.org/lkml/20260317025049.494931-4-pasha.tatashin@xxxxxxxxxx/