Linux Documentation
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: 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>,
	Christian Brauner <brauner@kernel.org>,
	 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 09/10] mm/shmem_luo: Allow retrieving tmpfs files with O_RDONLY
Date: Wed, 04 Nov 2026 17:52:34 +0100	[thread overview]
Message-ID: <2vxz5wyck08d.fsf@kernel.org> (raw)
In-Reply-To: <20261103010216.3447716-10-dmatlack@google.com> (David Matlack's message of "Tue, 3 Nov 2026 01:02:15 +0000")

On Tue, Nov 03 2026, David Matlack wrote:

> Allow userspace to pass O_RDONLY in struct liveupdate_shmem_retrieve_arg
> to retrieve a tmpfs file read-only.
>
> open() requires write access for O_TMPFILE, so create the file writable
> like before, then reopen it read-only with dentry_open() using the flags
> of the writable file, which file_open_root() normalized, and drop the
> writable file. Like open(), which grants the requested access to a new
> file regardless of its mode, don't check permission for the read-only
> open.
>
> Retrieving a file read-only allows a restored binary to be executed
> before the session is finished. LUO keeps the retrieved file open until
> then, and executing a binary that is open for writing fails with
> -ETXTBSY. Being able to execute restored binaries right away matters
> when they are needed to finish restoring the system, e.g. to bring up
> the services that retrieve and finish the remaining sessions.

Can't you put all your binaries in a separate session, retrieve it as
the very first thing, and then finish the session? Then you can execute
those and retrieve all the other sessions.

Why do we need to support this in the kernel?

Also, please put the motivation as on the top-ish of the commit message,
and the mechanics later. For example, your second paragraph should
likely come below this one.

[...]

-- 
Regards,
Pratyush Yadav

  parent reply	other threads:[~2026-11-04 16:52 UTC|newest]

Thread overview: 26+ 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 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 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 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 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 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 15:01   ` 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 16:27   ` 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 16:45   ` Pratyush Yadav
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 16:52   ` Pratyush Yadav [this message]
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 16:59   ` Pratyush Yadav

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=2vxz5wyck08d.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox