From: David Matlack <dmatlack@google.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: rppt@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, pratyush@kernel.org
Subject: Re: [PATCH v2 3/8] liveupdate: Remove file handler module refcounting
Date: Wed, 25 Mar 2026 06:14:55 -0700 [thread overview]
Message-ID: <CALzav=eGYJAFH+yhoMH76rM3U8L-_H12=UsvaN1v8hgn8BPhiQ@mail.gmail.com> (raw)
In-Reply-To: <CA+CK2bCU=4XQQJ_-3HrhbENBNWoDf=ZzHpp66nZaPxGUAU=U9g@mail.gmail.com>
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].
[1] https://lore.kernel.org/lkml/20260317025049.494931-4-pasha.tatashin@soleen.com/
next prev parent reply other threads:[~2026-03-25 13:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 14:16 [PATCH v2 0/8] liveupdate: Fix module unloading and unregister API Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 1/8] liveupdate: Protect file handler list with rwsem Pasha Tatashin
2026-03-22 13:13 ` Mike Rapoport
2026-03-22 14:23 ` Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 2/8] liveupdate: Protect FLB lists " Pasha Tatashin
2026-03-20 0:21 ` Samiullah Khawaja
2026-03-20 1:04 ` Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 3/8] liveupdate: Remove file handler module refcounting Pasha Tatashin
2026-03-24 21:15 ` David Matlack
2026-03-24 21:23 ` David Matlack
2026-03-25 2:49 ` Pasha Tatashin
2026-03-25 13:14 ` David Matlack [this message]
2026-03-25 13:43 ` Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 4/8] liveupdate: Defer FLB module refcounting to active sessions Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 5/8] liveupdate: Remove luo_session_quiesce() Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 6/8] liveupdate: Auto unregister FLBs on file handler unregistration Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 7/8] liveupdate: Remove liveupdate_test_unregister() Pasha Tatashin
2026-03-18 14:16 ` [PATCH v2 8/8] liveupdate: Make unregister functions return void Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALzav=eGYJAFH+yhoMH76rM3U8L-_H12=UsvaN1v8hgn8BPhiQ@mail.gmail.com' \
--to=dmatlack@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox