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

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

On Wed, Mar 25, 2026 at 9:15 AM David Matlack <dmatlack@google.com> wrote:
>
> On Tue, Mar 24, 2026 at 7:49 PM Pasha Tatashin
> <pasha.tatashin@soleen.com> wrote:
> >
> > On Tue, Mar 24, 2026 at 5:24 PM David Matlack <dmatlack@google.com> wrote:
> > >
> > > On Wed, Mar 18, 2026 at 7:17 AM Pasha Tatashin
> > > <pasha.tatashin@soleen.com> 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].

Great, I will include this in v3, together with Sami's suggestion for
lock simplifications.

Pasha

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