From: Pratyush Yadav <pratyush@kernel.org>
To: Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH 2/3] mm: memfd_luo: use memfd_alloc_file() instead of shmem_file_setup()
Date: Thu, 22 Jan 2026 16:18:40 +0100 [thread overview]
Message-ID: <20260122151842.4069702-3-pratyush@kernel.org> (raw)
In-Reply-To: <20260122151842.4069702-1-pratyush@kernel.org>
From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
When restoring a memfd, the file is created using shmem_file_setup().
While memfd creation also calls this function to get the file, it also
does other things:
1. The O_LARGEFILE flag is set on the file. If this is not done,
writes on the memfd exceeding 2 GiB fail.
2. FMODE_LSEEK, FMODE_PREAD, and FMODE_PWRITE are set on the file.
This makes sure the file is seekable and can be used with pread() and
pwrite().
3. Initializes the security field for the inode and makes sure that
inode creation is permitted by the security module.
Currently, none of those things are done. This means writes above 2 GiB
fail, pread(), and pwrite() fail, and so on. lseek() happens to work
because file_init_path() sets it because shmem defines fop->llseek.
Fix this by using memfd_alloc_file() to get the file to make sure the
initialization sequence for normal and preserved memfd is the same.
Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd")
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---
mm/memfd_luo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index 4f6ba63b4310..01a72e4d3ef6 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -78,6 +78,7 @@
#include <linux/liveupdate.h>
#include <linux/shmem_fs.h>
#include <linux/vmalloc.h>
+#include <linux/memfd.h>
#include "internal.h"
static int memfd_luo_preserve_folios(struct file *file,
@@ -443,8 +444,7 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
if (!ser)
return -EINVAL;
- file = shmem_file_setup("", 0, VM_NORESERVE);
-
+ file = memfd_alloc_file("", 0);
if (IS_ERR(file)) {
pr_err("failed to setup file: %pe\n", file);
return PTR_ERR(file);
--
2.52.0.457.g6b5491de43-goog
next prev parent reply other threads:[~2026-01-22 15:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 15:18 [PATCH 0/3] mm: memfd_luo hotfixes Pratyush Yadav
2026-01-22 15:18 ` [PATCH 1/3] memfd: export alloc_file() Pratyush Yadav
2026-01-22 15:44 ` Mike Rapoport
2026-01-22 18:00 ` Pasha Tatashin
2026-01-22 15:18 ` Pratyush Yadav [this message]
2026-01-22 15:45 ` [PATCH 2/3] mm: memfd_luo: use memfd_alloc_file() instead of shmem_file_setup() Mike Rapoport
2026-01-22 18:01 ` Pasha Tatashin
2026-01-22 15:18 ` [PATCH 3/3] mm: memfd_luo: restore and free memfd_luo_ser on failure Pratyush Yadav
2026-01-22 15:46 ` Mike Rapoport
2026-01-22 18:03 ` Pasha Tatashin
2026-01-22 15:31 ` [PATCH 0/3] mm: memfd_luo hotfixes Andrew Morton
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=20260122151842.4069702-3-pratyush@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@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