linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	 rppt@kernel.org, pratyush@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 14:47:06 +0100	[thread overview]
Message-ID: <gdu6kqpymqgkzbw2yrvvsrububimn2ocuyi533d6llofqu32kd@sqc6d6hsuzic> (raw)
In-Reply-To: <20260317023834.487682-1-pasha.tatashin@soleen.com>

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@soleen.com>
> ---
> 
> 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@suse.cz>

Just one nit below:

> [1] https://lore.kernel.org/all/20260129212510.967611-1-dmatlack@google.com
> [2] https://lore.kernel.org/all/20260203220948.2176157-1-skhawaja@google.com
> 
> @@ -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.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR


  parent reply	other threads:[~2026-03-20 13:47 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
2026-03-20 13:47 ` Jan Kara [this message]
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=gdu6kqpymqgkzbw2yrvvsrububimn2ocuyi533d6llofqu32kd@sqc6d6hsuzic \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.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 \
    --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