From: sashiko-bot@kernel.org
To: "Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Hugh Dickins" <hughd@google.com>,
"Mike Rapoport" <rppt@kernel.org>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Samiullah Khawaja" <skhawaja@google.com>,
"Alexander Graf" <graf@amazon.com>,
"David Matlack" <dmatlack@google.com>,
"Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>
Cc: kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 4/6] mm/memfd_luo: allow preserving a tmpfs mount
Date: Wed, 23 Sep 2026 23:06:44 +0000 [thread overview]
Message-ID: <20260923230644.E847A1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260923224408.3745689-5-pratyush@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] mm: tmpfs LUO drops group quotas due to incomplete USRQUOTA check
- [Medium] mm: TOCTOU race allows unsupported ID mappings and quotas to bypass LUO validation
--
commit 20e62ff0b162f0ffc76cd0d972cc6c760a83d003
Author: Pratyush Yadav (Google) <pratyush@kernel.org>
mm/memfd_luo: allow preserving a tmpfs mount
This commit adds support for preserving a tmpfs mount across a live update.
It preserves the filesystem block limit and root directory mode, while
resetting other options to default, identifying the mount via a file
pointing to it.
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
[ ... ]
> +static bool tmpfs_luo_mnt_can_preserve(struct liveupdate_file_handler *fh,
> + struct file *file)
> +{
[ ... ]
> + /* These features are not supported. */
> + if (SHMEM_SB(sb)->mpol || sb_has_quota_active(sb, USRQUOTA) ||
> + sb_has_encoding(sb) || is_idmapped_mnt(mnt))
> + return false;
[Severity: Medium]
Does this condition improperly accept tmpfs mounts with group or project
quotas active?
The check only tests for USRQUOTA, which means mounts with grpquota or
prjquota will bypass this rejection and their quota state will be silently
lost across kexec.
Should this use sb_any_quota_loaded(sb) to properly detect all quota types?
[ ... ]
> +static int tmpfs_luo_mnt_freeze(struct liveupdate_file_op_args *args)
> +{
> + struct super_block *sb = args->file->f_path.mnt->mnt_sb;
> + struct shmem_sb_info *sbinfo = SHMEM_SB(sb);
> + struct tmpfs_luo_mnt_ser *ser;
> +
> + /*
> + * A remount can install a memory policy after can_preserve() accepted
> + * the mount.
> + */
> + if (sbinfo->mpol)
> + return -EOPNOTSUPP;
[Severity: Medium]
Does this leave a TOCTOU window for ID mappings and quotas?
While mpol is re-validated here to handle concurrent remounts, checks for
is_idmapped_mnt() and quotas are missing. If a user concurrently adds an ID
mapping via mount_setattr() or enables quotas via remount after the
tmpfs_luo_mnt_can_preserve() check passes, those unsupported properties will
bypass validation and be silently dropped across kexec.
Should this re-validate the ID mapping and quota state as well?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923224408.3745689-1-pratyush@kernel.org?part=4
next prev parent reply other threads:[~2026-09-23 23:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 22:43 [RFC PATCH 0/6] luo: tmpfs preservation Pratyush Yadav
2026-09-23 22:44 ` [RFC PATCH 1/6] liveupdate: luo_file: look up outgoing tokens by id Pratyush Yadav
2026-09-23 22:55 ` sashiko-bot
2026-09-24 13:26 ` Pratyush Yadav
2026-09-23 22:44 ` [RFC PATCH 2/6] shmem: add tmpfs_create_mount() to create tmpfs mounts internally Pratyush Yadav
2026-09-23 22:54 ` sashiko-bot
2026-09-23 22:44 ` [RFC PATCH 3/6] fs/namespace: Add vfs_open_detached_mount() Pratyush Yadav
2026-09-23 23:01 ` sashiko-bot
2026-09-23 22:44 ` [RFC PATCH 4/6] mm/memfd_luo: allow preserving a tmpfs mount Pratyush Yadav
2026-09-23 23:06 ` sashiko-bot [this message]
2026-09-23 22:44 ` [RFC PATCH 5/6] mm/memfd_luo: allow preserving a tmpfs file Pratyush Yadav
2026-09-23 23:24 ` sashiko-bot
2026-09-23 22:44 ` [RFC PATCH 6/6] selftests/liveupdate: add tmpfs kexec test Pratyush Yadav
2026-09-23 23:14 ` sashiko-bot
2026-09-24 21:10 ` [RFC PATCH 0/6] luo: tmpfs preservation 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=20260923230644.E847A1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=hughd@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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
all inboxes | Powered by JetHome®