--------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.232.135.74 listed in list.dnswl.org] 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.232.135.74 listed in zen.spamhaus.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: "Pratyush Yadav (Google)" A dirty folio is one which has been written to. A clean folio is its opposite. Since a clean folio has no user data, it can be freed under memory pressure. memfd preservation with LUO saves the flag at preserve(). This is problematic. The folio might get dirtied later. Saving it at freeze() also doesn't work, since the dirty bit from PTE is normally synced at unmap and there might still be mappings of the file at freeze(). To see why this is a problem, say a folio is clean at preserve, but gets dirtied later. The serialized state of the folio will mark it as clean. After retrieve, the next kernel will see the folio as clean and might try to reclaim it under memory pressure. This will result in losing user data. Mark all folios of the file as dirty, and always set the MEMFD_LUO_FOLIO_DIRTY flag. This comes with the side effect of making all clean folios un-reclaimable. This is a cost that has to be paid for participants of live update. It is not expected to be a common use case to preserve a lot of clean folios anyway. Since the value of pfolio->flags is a constant now, drop the flags variable and set it directly. Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd") Cc: stable@vger.kernel.org Signed-off-by: Pratyush Yadav (Google) --- mm/memfd_luo.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c index ccbf1337f650..9eac02d06b5a 100644 --- a/mm/memfd_luo.c +++ b/mm/memfd_luo.c @@ -146,7 +146,6 @@ static int memfd_luo_preserve_folios(struct file *file, for (i = 0; i < nr_folios; i++) { struct memfd_luo_folio_ser *pfolio = &folios_ser[i]; struct folio *folio = folios[i]; - unsigned int flags = 0; err = kho_preserve_folio(folio); if (err) @@ -154,8 +153,26 @@ static int memfd_luo_preserve_folios(struct file *file, folio_lock(folio); - if (folio_test_dirty(folio)) - flags |= MEMFD_LUO_FOLIO_DIRTY; + /* + * A dirty folio is one which has been written to. A clean folio + * is its opposite. Since a clean folio does not carry user + * data, it can be freed by page reclaim under memory pressure. + * + * Saving the dirty flag at prepare() time doesn't work since it + * can change later. Saving it at freeze() also won't work + * because the dirty bit is normally synced at unmap and there + * might still be a mapping of the file at freeze(). + * + * To see why this is a problem, say a folio is clean at + * preserve, but gets dirtied later. The pfolio flags will mark + * it as clean. After retrieve, the next kernel might try to + * reclaim this folio under memory pressure, losing user data. + * + * Unconditionally mark it dirty to avoid this problem. This + * comes at the cost of making clean folios un-reclaimable after + * live update. + */ + folio_mark_dirty(folio); /* * If the folio is not uptodate, it was fallocated but never @@ -174,12 +191,11 @@ static int memfd_luo_preserve_folios(struct file *file, flush_dcache_folio(folio); folio_mark_uptodate(folio); } - flags |= MEMFD_LUO_FOLIO_UPTODATE; folio_unlock(folio); pfolio->pfn = folio_pfn(folio); - pfolio->flags = flags; + pfolio->flags = MEMFD_LUO_FOLIO_DIRTY | MEMFD_LUO_FOLIO_UPTODATE; pfolio->index = folio->index; } -- 2.53.0.371.g1d285c8824-goog From - Mon Feb 23 17:42:47 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 2K9QE5ORnGlyiDkAYBR5ng (envelope-from ) for ; Mon, 23 Feb 2026 17:42:43 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 23 Feb 2026 17:42:43 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vuZxC-0000000HFjW-3k0y for hi@josie.lol; Mon, 23 Feb 2026 17:42:43 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id E7729300DE3E for ; Mon, 23 Feb 2026 17:39:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6BA5C334685; Mon, 23 Feb 2026 17:39:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wxu/8cLi" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 068C5332EB4; Mon, 23 Feb 2026 17:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771868350; cv=none; b=U2kvYgQ0Uh1scgjXDqz72IBzsAvfnJkAHXEKyVgHTKxXAkrjX99+KkhzjFYKMtisVQyRnlPBzq+0M/mLJObAzp9naypwoN7SyDxBEzypuoQrYwZSZIbHVAGwlh9yraI/z+mRM7C2b+cSwAV2Lt4B/QZWha+tQ0mnsQr3tIYumPc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771868350; c=relaxed/simple; bh=qW9i6zN1CY6w+IeHjsOXHWptGUB6blB9XwWVVi+sh1g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gXPE7UELajyeIkkSCMMSa5U45zmH4OUnn80XUCgH+Q8WanTx104rCbLQKmYo0EpaE7PY4XdFuyeYjjEB1qfuS0f/mUBOxLSiOtV/m4AECsehelmmlaVezRB647IlMYpzHdlspAJR58kdogi23q6Y6qsppBFegrXmQPL+OjpE/RQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wxu/8cLi; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74C1EC116C6; Mon, 23 Feb 2026 17:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771868349; bh=qW9i6zN1CY6w+IeHjsOXHWptGUB6blB9XwWVVi+sh1g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Wxu/8cLigHMnzGFEcQNnYenuwJd9vXt+eU8fmhzNlvcNnWrR33idDVrz8YJ8qZ8gt sit1aDhavzpGKZqmNzq7HrFUWgnp//z5HMvlNmHq8AAmtREXxi/elr3TceAnwnrcFF /VevfSQhsH97GE1xcZsAEsNDV3hU/XGigy72iojdrO6PZE0hz2XRYC6EPcqziISq0b WoNh1FD