From nobody Tue Dec 2 00:25:57 2025 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFACD32FA1D for ; Tue, 25 Nov 2025 16:59:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764089971; cv=none; b=payzZQ4FM+m5s9vgb2cu7HriHmAdg8AXmw6ElbJiIx0R12BVPjFo6iXaGINHEuyIj/VvvtoGm+atU1Xb+ene/tcftb0f/RyipgM4ZRoFkO1+/fF62NyoMp8Zw1OIkE2Nzh2CI5NZPotJ0+L2qgORug5Z/rr6e2J9FcESTNVf0og= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764089971; c=relaxed/simple; bh=v9x1l0vuGtuabHoTMFaYXgKBzUw5ntyOjf/K0GgYcpQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GnSyveZRsBcKifglXsHpJ45tGW/nkRzFJPFPfWFStbihy1A5Qt0XYfO0IDSgBxPunKh4J7AuxVLJlY9GaVD7HUHTmGycD5KVtQNWVflJZgOYtkydlM/t6yLrkVphvoQNbU0G7smrampGMvJQr+I29d2NspmBr9jWvw5gBznJiUc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b=RHTRwS3T; arc=none smtp.client-ip=209.85.128.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="RHTRwS3T" Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-78802ac22abso62168607b3.3 for ; Tue, 25 Nov 2025 08:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1764089969; x=1764694769; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=rLwSseklhA0qKOMy2cW44bpZPsfi2vW7qm+LuafppIg=; b=RHTRwS3TjRxpHzWC/9ffzr7awvtTYzVC/0U1YqseCVowNj/dj8nGzpSJqTycG4IaDq GCr2a+udzcuwCfRBPYazhM8QKRikvGRtZy7XRFieZ9jwTFgeVgjKLeXugMN9gELR9iRr kNNO/I3ne61l9VgD8XNgtlbPxJzCuFeoxLmEnQ8Vm6XqTzGEROQxbsZc8uRrCY4jpncj z3Wc3PEAWLGPVwFype8cqGHkYRfjBN4up/Hb1Qcr7FhLYTYQV61bIicobWa0QRPp7HJd rOlixgWvqOB6AROT4kxNDrLH4Yz6SAbesWFUMwdhZUAHcyQwa9WyBlYI6O9Ao03k7Vds Yoeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764089969; x=1764694769; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=rLwSseklhA0qKOMy2cW44bpZPsfi2vW7qm+LuafppIg=; b=cBO1w+zo83dDy6QOkua6aXvQHXLf7NDoROY5iPJtkpM0l7dtgC/orZREs1p/s2/6Za UTYJiog+s9Eztm8lVS+FxqpvzdDJlkg/J4wtIwlJx3+VXqzlBWZQFChgUCbx86jkXHfR 5boR0gup4LYDNP/grytIiNhNPpc0wKRQXPPAq43/mikh4AJOiHoLV1rAhot2SI3jf4XM Tw/RKGuTQfwUdEQjKwGBJh0wxyzi4R9i7tTBeRwl8ViPcsTUoWE4wCvUy5YEnq4pIqiA rFXWPkh1oF2FzxP8pUkVsN9HATDvql3hwTFfCmDWs1c5gcnbAPCWphMkQOgVE7WCHPjD ST+g== X-Forwarded-Encrypted: i=1; AJvYcCWhIBFN/aogdM7w3gT/9mvCFUoodU1I1v48uoB7X9zO0S68U+MpGbPr3QPoKB954j5LAcjLcEKMz+qUX18=@vger.kernel.org X-Gm-Message-State: AOJu0YyFBLXBQTn4O3YXBjmxC71zd6Dh8aOFLVRfNASxWU8hIT3TlJ9c zoFheGKwZJ7tnXY+E+u1Cde9JQgX1RbzY9OuQ5TNAwfMdELZ4tO6nVMpNglg3uVnTTU= X-Gm-Gg: ASbGncszxVCGFX3IK5qGpbZ2gsV+SWlVnS6KzTWPXgVlFFx0XLxRqz3Cc0nEGeVF/CY dYMwA4c/LFV+Ia30WeWjXsKW2ukv7IY2K/uFUvksM0jbXXlLbBwCCfIVv1R8xeA25M9GDFhBQCs J4RIrUxGpYQQco/44e1bfwtaHxwKgwU66PUkk5V6djM/ku4MkDObfYZ20jKp3U/MPAdtlmUifHQ unAm65ROsvilZdkWrdfu17c2zopO723x9WHWH2u9zOcFDV6HlSa6iIdBFWokFn2y4XPXkM0e7WY m9o+/QXakJOyLNOdUE1D5FMpOBL0pDLEaTurZnP3tiD5GgWsq0f5QyxhQCEv0qabLMxETR7DbKm 3Uyec48wMMs92MVc3HywQkE/fekfqEyvtt+2LOOA1FdjXMLv98Kte3dHNAxnLwTnplWspCEDbuQ JxXgLahqHMv6sVLHzy2WVvYG0B4VhqFXQ5OgpEt9/k2LTHoyW9NPUWM+6DpH726+T/athny/tYu Tw= X-Google-Smtp-Source: AGHT+IHyOGiEIWn7K/FqPN8HAm8rR5ND4rL8A082/WWeW+u5rZ2m5KAWzpxwpgtD4aV75ucYKtS3TQ== X-Received: by 2002:a05:690c:4b08:b0:788:1086:8834 with SMTP id 00721157ae682-78ab6d811b4mr30671357b3.12.1764089968779; Tue, 25 Nov 2025 08:59:28 -0800 (PST) Received: from soleen.c.googlers.com.com (182.221.85.34.bc.googleusercontent.com. [34.85.221.182]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a798a5518sm57284357b3.14.2025.11.25.08.59.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Nov 2025 08:59:28 -0800 (PST) From: Pasha Tatashin To: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com, pasha.tatashin@soleen.com, rppt@kernel.org, dmatlack@google.com, rientjes@google.com, corbet@lwn.net, rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr, mmaurer@google.com, roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, dan.j.williams@intel.com, david@redhat.com, joel.granados@kernel.org, rostedt@goodmis.org, anna.schumaker@oracle.com, song@kernel.org, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, rafael@kernel.org, dakr@kernel.org, bartosz.golaszewski@linaro.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, yesanishhere@gmail.com, Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com, aleksander.lobakin@intel.com, ira.weiny@intel.com, andriy.shevchenko@linux.intel.com, leon@kernel.org, lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org, djeffery@redhat.com, stuart.w.hayes@gmail.com, ptyadav@amazon.de, lennart@poettering.net, brauner@kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, saeedm@nvidia.com, ajayachandra@nvidia.com, jgg@nvidia.com, parav@nvidia.com, leonro@nvidia.com, witu@nvidia.com, hughd@google.com, skhawaja@google.com, chrisl@kernel.org Subject: [PATCH v8 11/18] mm: shmem: allow freezing inode mapping Date: Tue, 25 Nov 2025 11:58:41 -0500 Message-ID: <20251125165850.3389713-12-pasha.tatashin@soleen.com> X-Mailer: git-send-email 2.52.0.460.gd25c4c69ec-goog In-Reply-To: <20251125165850.3389713-1-pasha.tatashin@soleen.com> References: <20251125165850.3389713-1-pasha.tatashin@soleen.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pratyush Yadav To prepare a shmem inode for live update, its index -> folio mappings must be serialized. Once the mappings are serialized, they cannot change since it would cause the serialized data to become inconsistent. This can be done by pinning the folios to avoid migration, and by making sure no folios can be added to or removed from the inode. While mechanisms to pin folios already exist, the only way to stop folios being added or removed are the grow and shrink file seals. But file seals come with their own semantics, one of which is that they can't be removed. This doesn't work with liveupdate since it can be cancelled or error out, which would need the seals to be removed and the file's normal functionality to be restored. Introduce SHMEM_F_MAPPING_FROZEN to indicate this instead. It is internal to shmem and is not directly exposed to userspace. It functions similar to F_SEAL_GROW | F_SEAL_SHRINK, but additionally disallows hole punching, and can be removed. Signed-off-by: Pratyush Yadav Signed-off-by: Pasha Tatashin Reviewed-by: Mike Rapoport (Microsoft) --- include/linux/shmem_fs.h | 17 +++++++++++++++++ mm/shmem.c | 11 +++++++++++ 2 files changed, 28 insertions(+) diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h index 650874b400b5..d34a64eafe60 100644 --- a/include/linux/shmem_fs.h +++ b/include/linux/shmem_fs.h @@ -24,6 +24,14 @@ struct swap_iocb; #define SHMEM_F_NORESERVE BIT(0) /* Disallow swapping. */ #define SHMEM_F_LOCKED BIT(1) +/* + * Disallow growing, shrinking, or hole punching in the inode. Combined wi= th + * folio pinning, makes sure the inode's mapping stays fixed. + * + * In some ways similar to F_SEAL_GROW | F_SEAL_SHRINK, but can be removed= and + * isn't directly visible to userspace. + */ +#define SHMEM_F_MAPPING_FROZEN BIT(2) =20 struct shmem_inode_info { spinlock_t lock; @@ -186,6 +194,15 @@ static inline bool shmem_file(struct file *file) return shmem_mapping(file->f_mapping); } =20 +/* Must be called with inode lock taken exclusive. */ +static inline void shmem_freeze(struct inode *inode, bool freeze) +{ + if (freeze) + SHMEM_I(inode)->flags |=3D SHMEM_F_MAPPING_FROZEN; + else + SHMEM_I(inode)->flags &=3D ~SHMEM_F_MAPPING_FROZEN; +} + /* * If fallocate(FALLOC_FL_KEEP_SIZE) has been used, there may be pages * beyond i_size's notion of EOF, which fallocate has committed to reservi= ng: diff --git a/mm/shmem.c b/mm/shmem.c index 1d5036dec08a..786573479360 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1297,6 +1297,8 @@ static int shmem_setattr(struct mnt_idmap *idmap, return -EPERM; =20 if (newsize !=3D oldsize) { + if (info->flags & SHMEM_F_MAPPING_FROZEN) + return -EPERM; error =3D shmem_reacct_size(SHMEM_I(inode)->flags, oldsize, newsize); if (error) @@ -3289,6 +3291,10 @@ shmem_write_begin(const struct kiocb *iocb, struct a= ddress_space *mapping, return -EPERM; } =20 + if (unlikely((info->flags & SHMEM_F_MAPPING_FROZEN) && + pos + len > inode->i_size)) + return -EPERM; + ret =3D shmem_get_folio(inode, index, pos + len, &folio, SGP_WRITE); if (ret) return ret; @@ -3662,6 +3668,11 @@ static long shmem_fallocate(struct file *file, int m= ode, loff_t offset, =20 inode_lock(inode); =20 + if (info->flags & SHMEM_F_MAPPING_FROZEN) { + error =3D -EPERM; + goto out; + } + if (mode & FALLOC_FL_PUNCH_HOLE) { struct address_space *mapping =3D file->f_mapping; loff_t unmap_start =3D round_up(offset, PAGE_SIZE); --=20 2.52.0.460.gd25c4c69ec-goog