Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Samiullah Khawaja <skhawaja@google.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v2 2/2] mm/memfd_luo: keep memfd frozen until finish
Date: Sat, 14 Nov 2026 22:05:28 -0800	[thread overview]
Message-ID: <20261114220528.f7d9874a014dbb5d@chrisdown.name> (raw)
In-Reply-To: <20261110175855.2437084-3-pratyush@kernel.org>

Hi Pratyush,

Pratyush Yadav writes:
>+ * Restrictions
>+ * ============
>+ *
>+ * While a memfd is preserved, and after it is retrieved until the session is
>+ * finished, its size can't be changed and holes can't be punched in it.
>+ * Operations that would do so (``ftruncate()``, ``fallocate()``, writes past
>+ * the end of the file) fail.

Not a big deal, but there's one more thing that fails in this window and
isn't listed here. Adding F_SEAL_WRITE to a retrieved memfd before finish
now waits about 150ms and then fails with EBUSY. That's because
memfd_wait_for_pins() sees the reference kept from kho_restore_folio() as
an extra reference on every folio. Once the session is finished it
succeeds straight away. The same already happens while the memfd is
preserved in the old kernel, so maybe it's worth mentioning here for both?

Also, fallocate() fails with EPERM in every mode while the file is frozen.
That includes FALLOC_FL_KEEP_SIZE inside i_size, which neither changes the
size nor punches a hole. "Operations that would do so" makes it sound like
only some fallocate() calls fail.

Otherwise I've tested this across a kexec and it works well.

Once those are fixed, please feel free to add:

Reviewed-by: Chris Down <chris@chrisdown.name>
Tested-by: Chris Down <chris@chrisdown.name>

Thanks!

Chris


      parent reply	other threads:[~2026-11-15  6:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 17:58 [PATCH v2 0/2] memfd_luo: keep memfd frozen until finish Pratyush Yadav
2026-11-10 17:58 ` [PATCH v2 1/2] liveupdate: luo_file: allow keeping private_data from retrieve " Pratyush Yadav
2026-11-10 18:29   ` Samiullah Khawaja
2026-11-15  6:05   ` Chris Down
2026-11-10 17:58 ` [PATCH v2 2/2] mm/memfd_luo: keep memfd frozen " Pratyush Yadav
2026-11-10 18:36   ` Samiullah Khawaja
2026-11-15  6:05   ` Chris Down [this message]

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=20261114220528.f7d9874a014dbb5d@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=akpm@linux-foundation.org \
    --cc=kexec@lists.infradead.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=skhawaja@google.com \
    /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