From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: Christian Brauner <brauner@kernel.org>,
kexec@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, Alexander Graf <graf@amazon.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
David Hildenbrand <david@kernel.org>,
Hugh Dickins <hughd@google.com>,
Jonathan Corbet <corbet@lwn.net>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Samiullah Khawaja <skhawaja@google.com>,
Shuah Khan <skhan@linuxfoundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>
Subject: Re: [PATCH v3 00/10] liveupdate: Preserve tmpfs files across Live Update
Date: Tue, 10 Nov 2026 16:45:32 +0100 [thread overview]
Message-ID: <2vxzbj7witb7.fsf@kernel.org> (raw)
In-Reply-To: <auy0ThryqW5nVx20@google.com> (David Matlack's message of "Thu, 5 Nov 2026 16:52:30 +0000")
Hi David,
On Thu, Nov 05 2026, David Matlack wrote:
> On 2026-11-05 04:42 PM, Christian Brauner wrote:
>> On Tue, Nov 03, 2026 at 01:02:06AM +0000, David Matlack wrote:
[...]
>> So instead of LUO handing out a file descriptor for a file it invented,
>> let userspace create the file, O_TMPFILE, O_CREAT, whatever it likes,
>> with the owner, mode and xattrs it wants, and let LUO put the contents
>> into it. That's what the RFC did.
>
> I'm fine with going back to that in v4. The retrieve argument will just
> be a file descriptor for the target file, and LUO will only restore the
> contents and size into it. Everything else about the file is up to
> userspace.
>
>> The checks on the target are trivial: a writable fd to an empty shmem
>> file with the inode lock held while you fill it. A tmpfs file can't be
>> sealed, it only ever has F_SEAL_SEAL, so there's nothing to restore but
>> contents and size anyway.
>
> Sounds good. The one other check I plan to add is rejecting a target
> that LUO is already managing, e.g. a file that is preserved in an
> outgoing session and whose size is frozen.
I have been playing with this idea too, and I also stumbled onto this
problem.
You also need to make sure a preserve doesn't race with a retrieve.
Since userspace has access to the file, it can do both at the same time.
I think LUO should expose a "register file" function that registers the
file in luo_preserved_files. This should be the very first thing
retrieve does.
Also, today LUO core expects a fresh file from file handlers, so it
always installs a FD to that file in the task. When doing the "retrieve
into FD" thing, that will result in two FDs to the same file. While it
isn't a strict problem, it seems kinda ugly from a uAPI prespective.
Perhaps we should let retrieve signal to LUO core that "I already
installed the file", or a "I have no file to install", or something
similar?
>
> LUO will also add the folios while i_size is still 0, and set i_size
> last. So reads, page faults and memfd_pin_folios() wouldn't see the
> folios until the file is complete, and if the retrieve fails partway
> through the target is left empty.
>
[...]
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-11-10 15:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 1:02 [PATCH v3 00/10] liveupdate: Preserve tmpfs files across Live Update David Matlack
2026-11-03 1:02 ` [PATCH v3 01/10] liveupdate: Pass user argument to file preserve and retrieve David Matlack
2026-11-04 1:03 ` sashiko-bot
2026-11-04 13:17 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 02/10] selftests: liveupdate: Add tests for preserve and retrieve user argument David Matlack
2026-11-04 1:03 ` sashiko-bot
2026-11-04 13:26 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 03/10] liveupdate: Allow file handlers to mark retrieve failures as retryable David Matlack
2026-11-04 1:03 ` sashiko-bot
2026-11-04 14:12 ` Pratyush Yadav
2026-11-04 16:15 ` Pasha Tatashin
2026-11-03 1:02 ` [PATCH v3 04/10] mm: Rename memfd_luo to shmem_luo David Matlack
2026-11-04 1:03 ` sashiko-bot
2026-11-04 14:25 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 05/10] liveupdate: Don't WARN if tracking a retrieved file fails David Matlack
2026-11-04 1:03 ` sashiko-bot
2026-11-04 14:32 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 06/10] mm/shmem_luo: Don't make early retrieve failures permanent David Matlack
2026-11-04 1:03 ` sashiko-bot
2026-11-04 15:01 ` Pratyush Yadav
2026-11-04 22:28 ` David Matlack
2026-11-06 14:14 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 07/10] mm/shmem_luo: Retrieve tmpfs files onto a tmpfs mount chosen by userspace David Matlack
2026-11-04 0:43 ` Pasha Tatashin
2026-11-04 1:03 ` sashiko-bot
2026-11-04 16:27 ` Pratyush Yadav
2026-11-04 22:30 ` David Matlack
2026-11-06 14:20 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 08/10] mm/shmem_luo: Allow preserving tmpfs files that are still linked David Matlack
2026-11-04 0:43 ` Pasha Tatashin
2026-11-04 1:03 ` sashiko-bot
2026-11-04 16:45 ` Pratyush Yadav
2026-11-04 22:32 ` David Matlack
2026-11-04 23:38 ` David Matlack
2026-11-03 1:02 ` [PATCH v3 09/10] mm/shmem_luo: Allow retrieving tmpfs files with O_RDONLY David Matlack
2026-11-04 0:43 ` Pasha Tatashin
2026-11-04 1:03 ` sashiko-bot
2026-11-04 16:52 ` Pratyush Yadav
2026-11-04 19:45 ` Pasha Tatashin
2026-11-04 22:35 ` David Matlack
2026-11-06 14:11 ` Pratyush Yadav
2026-11-03 1:02 ` [PATCH v3 10/10] selftests/liveupdate: Add a test for preserving tmpfs files David Matlack
2026-11-04 0:43 ` Pasha Tatashin
2026-11-04 1:03 ` sashiko-bot
2026-11-04 16:59 ` Pratyush Yadav
2026-11-04 19:37 ` Pasha Tatashin
2026-11-04 22:42 ` David Matlack
2026-11-06 14:19 ` Pratyush Yadav
2026-11-05 15:42 ` [PATCH v3 00/10] liveupdate: Preserve tmpfs files across Live Update Christian Brauner
2026-11-05 16:52 ` David Matlack
2026-11-10 15:45 ` Pratyush Yadav [this message]
2026-11-10 18:56 ` David Matlack
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=2vxzbj7witb7.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=hughd@google.com \
--cc=kexec@lists.infradead.org \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=skhawaja@google.com \
--cc=surenb@google.com \
--cc=vbabka@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.