From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: David Carlier <devnexen@gmail.com>
Cc: akpm@linux-foundation.org, pratyush@kernel.org,
pasha.tatashin@soleen.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX
Date: Fri, 1 May 2026 18:59:47 +0000 [thread overview]
Message-ID: <afT3no4OkYxnQ6zJ@plex> (raw)
In-Reply-To: <20260423125648.152113-1-devnexen@gmail.com>
On 04-23 13:56, David Carlier wrote:
> memfd_luo_preserve_folios() declares max_folios as unsigned int and
> computes it from the inode size, then passes it to memfd_pin_folios()
> which itself caps max_folios at unsigned int. For files whose base-page
> count exceeds UINT_MAX (larger than 16 TiB with 4 KiB pages), the
> assignment truncates silently: only a prefix of the file gets pinned and
> preserved, while memfd_luo_preserve() still records the full inode size
> in ser->size. On retrieve the inode is restored to the full size but
> only the preserved prefix repopulates the page cache, so the tail comes
> back as holes and user data is silently lost across the live update.
>
> Reject such files at preserve time with -EFBIG rather than chunk the
> pin loop, which would also require enlarging the preserved folios array
> well beyond what is practical.
>
> Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd")
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
> mm/memfd_luo.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index b02b503c750d..f41d11053b7d 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -259,7 +259,7 @@ static int memfd_luo_preserve(struct liveupdate_file_op_args *args)
> struct inode *inode = file_inode(args->file);
> struct memfd_luo_folio_ser *folios_ser;
> struct memfd_luo_ser *ser;
> - u64 nr_folios;
> + u64 nr_folios, inode_size;
> int err = 0, seals;
>
> inode_lock(inode);
> @@ -285,7 +285,18 @@ static int memfd_luo_preserve(struct liveupdate_file_op_args *args)
> }
>
> ser->pos = args->file->f_pos;
> - ser->size = i_size_read(inode);
> + inode_size = i_size_read(inode);
> +
> + /*
> + * memfd_pin_folios() caps at UINT_MAX folios; refuse larger
> + * files to avoid silently preserving only a prefix.
> + */
I think, the fix should be first done at memfd_pin_folios() to change
max_folios to 'long' or 'unsigned long', and then just updated
memfd_luo.c to match.
Pasha
> + if (DIV_ROUND_UP_ULL(inode_size, PAGE_SIZE) > UINT_MAX) {
> + err = -EFBIG;
> + goto err_free_ser;
> + }
> +
> + ser->size = inode_size;
> ser->seals = seals;
>
> err = memfd_luo_preserve_folios(args->file, &ser->folios,
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-05-01 18:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 12:56 [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX David Carlier
2026-04-23 12:56 ` [PATCH 2/2] mm/memfd_luo: document preservation of file seals David Carlier
2026-05-01 19:41 ` Pasha Tatashin
2026-05-04 8:07 ` Pratyush Yadav
2026-05-01 18:59 ` Pasha Tatashin [this message]
2026-05-01 19:26 ` [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX David CARLIER
2026-05-01 19:38 ` Pasha Tatashin
2026-05-04 8:05 ` 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=afT3no4OkYxnQ6zJ@plex \
--to=pasha.tatashin@soleen.com \
--cc=akpm@linux-foundation.org \
--cc=devnexen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pratyush@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.