linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	rppt@kernel.org,  linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,  akpm@linux-foundation.org,
	linux-mm@kvack.org
Subject: Re: [RFC] liveupdate: prevent double preservation
Date: Fri, 20 Mar 2026 08:53:14 -0400	[thread overview]
Message-ID: <CA+CK2bC+U9BfPAScE4pvtd4BVbEZohy1xH9BT+_gN57_NQ-rZw@mail.gmail.com> (raw)
In-Reply-To: <2vxzqzpeaj1s.fsf@kernel.org>

On Fri, Mar 20, 2026 at 6:31 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> Hi Pasha,
>
> On Mon, Mar 16 2026, 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.
>
> For consistency, would it be a good idea to also set this flag after
> retrieve? And then clear it on finish? If we do that then I suppose we
> should rename the flag to I_LUO_MANAGED or something similar.

Hi Pratyush,

That is a good idea. Between the retrieve and finish operations, the
file still has limitations due to LUO ownership, so keeping it flagged
as managed is useful. For example, in memfd the memory should remain
pinned, and in iommu the DMA mappings cannot be resized until finish,
VFIO also has some limitations.

I will rename the flag to I_LUO_MANAGED and update the retrieve and
finish paths in the next version.

Pasha

>
> Other than this, LGTM from LUO perspective.
>
> Acked-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>
> [...]
>
> --
> Regards,
> Pratyush Yadav


  reply	other threads:[~2026-03-20 12:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17  2:38 Pasha Tatashin
2026-03-20 10:31 ` Pratyush Yadav
2026-03-20 12:53   ` Pasha Tatashin [this message]
2026-03-20 13:47 ` Jan Kara
2026-03-20 14:27   ` 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=CA+CK2bC+U9BfPAScE4pvtd4BVbEZohy1xH9BT+_gN57_NQ-rZw@mail.gmail.com \
    --to=pasha.tatashin@soleen.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pratyush@kernel.org \
    --cc=rppt@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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