From: sashiko-bot@kernel.org
To: "Haolong Wang" <18766350203@163.com>,
"Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Mike Rapoport" <rppt@kernel.org>,
"Pratyush Yadav" <pratyush@kernel.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>, kexec@lists.infradead.org
Subject: Re: [PATCH v2 2/2] mm/memfd_luo: release preserved folios when retrieve fails
Date: Wed, 14 Oct 2026 03:22:49 +0000 [thread overview]
Message-ID: <sashiko-outbox-170773@kernel.org> (raw)
In-Reply-To: <20261014031254.432582-3-18766350203@163.com>
> retrieve() only frees the serialization structure on its error paths, but
> the folios it describes are still preserved at that point:
> memfd_luo_finish() deliberately skips its own cleanup for records whose
> retrieve() failed, since it relies on retrieve() to have released them.
> The folios and the folio array are therefore never handed back and stay
> reserved in the next kernel.
>
> Release them from retrieve() as well, by sharing the cleanup with
> memfd_luo_finish(). After the record has been validated, the folio array
> is restored before the file is allocated, so a failure from
> memfd_alloc_file() or memfd_add_seals() can release the folios directly
> instead of allocating memory while already handling a failure; a record
> this version does not support is rejected before that and uses the shared
> cleanup too. The folios may only be released while they are still fully
> preserved: once memfd_luo_retrieve_folios() has run it has consumed every
> [ ... ]
> by Sashiko AI review).
>
> Fixes: f85b1c6af5bc ("liveupdate: luo_file: remember retrieve() status")
> Assisted-by: Pi:glm-5.3-flash
> Signed-off-by: Haolong Wang <18766350203@163.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014031254.432582-1-18766350203@163.com?part=2
prev parent reply other threads:[~2026-10-14 3:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 3:12 [PATCH v2 0/2] mm/memfd_luo: preserve the sealed exec-bit state; fix retrieve() leaks Haolong Wang
2026-10-14 3:12 ` [PATCH v2 1/2] mm/memfd_luo: carry the sealed exec-bit state in the preserved record Haolong Wang
2026-10-14 3:26 ` sashiko-bot
2026-10-14 3:52 ` Haolong Wang
2026-10-14 3:12 ` [PATCH v2 2/2] mm/memfd_luo: release preserved folios when retrieve fails Haolong Wang
2026-10-14 3:22 ` sashiko-bot [this message]
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=sashiko-outbox-170773@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=18766350203@163.com \
--cc=akpm@linux-foundation.org \
--cc=kexec@lists.infradead.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.