From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,urezki@gmail.com,glider@google.com,elver@google.com,dvyukov@google.com,dmytrokoziuk68@gmail.com,akpm@linux-foundation.org
Subject: [merged mm-stable] mm-kmsan-fix-ioremap-error-cleanup.patch removed from -mm tree
Date: Sat, 24 Oct 2026 02:00:48 -0700 [thread overview]
Message-ID: <20261024090048.D4AD21F01828@smtp.kernel.org> (raw)
The quilt patch titled
Subject: mm: kmsan: fix ioremap error cleanup
has been removed from the -mm tree. Its filename was
mm-kmsan-fix-ioremap-error-cleanup.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Dima Koziuk <dmytrokoziuk68@gmail.com>
Subject: mm: kmsan: fix ioremap error cleanup
Date: Fri, 2 Oct 2026 23:05:08 +0300
Looking further at kmsan_ioremap_page_range(), I found three cases where
error cleanup leaks metadata blocks.
1. If the first iteration fails, clean is zero and cleanup is skipped,
leaking any allocations that succeeded in that iteration.
2. If shadow mapping succeeds but origin mapping fails, the shadow
pointer has already been cleared. Removing its mapping loses the
backing block.
3. On failures after completed iterations, cleanup removes the earlier
metadata mappings without freeing their backing blocks.
The cleanup needed here is the same as for iounmap, so it makes sense to
reuse kmsan_iounmap_pages(). Track the end of installed mappings with
mapped_end and advance it after each successful shadow mapping. This
includes the current shadow block if origin mapping subsequently fails,
while the helper skips the missing origin mapping.
Run cleanup whenever err is non-zero. Free allocations that have not been
mapped directly, and use the shared helper to unmap and free the installed
metadata, including blocks from completed iterations.
Link: https://lore.kernel.org/20261002200508.546-2-dmytrokoziuk68@gmail.com
Fixes: fdea03e12aa2 ("mm: kmsan: handle alloc failures in kmsan_ioremap_page_range()")
Signed-off-by: Dima Koziuk <dmytrokoziuk68@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
mm/kmsan/hooks.c | 35 ++++++++++++-----------------------
1 file changed, 12 insertions(+), 23 deletions(-)
--- a/mm/kmsan/hooks.c~mm-kmsan-fix-ioremap-error-cleanup
+++ a/mm/kmsan/hooks.c
@@ -186,16 +186,17 @@ int kmsan_ioremap_page_range(unsigned lo
gfp_t gfp_mask = GFP_KERNEL | __GFP_ZERO;
struct page *shadow, *origin;
unsigned long off = 0;
- int nr, err = 0, clean = 0, mapped;
+ unsigned long mapped_end = start;
+ int nr, err = 0, mapped;
if (!kmsan_enabled || kmsan_in_runtime())
return 0;
nr = (end - start) / PAGE_SIZE;
kmsan_enter_runtime();
- for (int i = 0; i < nr; i++, off += PAGE_SIZE, clean = i) {
- shadow = alloc_pages(gfp_mask, 1);
- origin = alloc_pages(gfp_mask, 1);
+ for (int i = 0; i < nr; i++, off += PAGE_SIZE) {
+ shadow = alloc_pages(gfp_mask, KMSAN_IOREMAP_META_ORDER);
+ origin = alloc_pages(gfp_mask, KMSAN_IOREMAP_META_ORDER);
if (!shadow || !origin) {
err = -ENOMEM;
goto ret;
@@ -209,39 +210,27 @@ int kmsan_ioremap_page_range(unsigned lo
goto ret;
}
shadow = NULL;
+ mapped_end = start + off + PAGE_SIZE;
mapped = __vmap_pages_range_noflush(
vmalloc_origin(start + off),
vmalloc_origin(start + off + PAGE_SIZE), prot, &origin,
PAGE_SHIFT);
if (mapped) {
- __vunmap_range_noflush(
- vmalloc_shadow(start + off),
- vmalloc_shadow(start + off + PAGE_SIZE));
err = mapped;
goto ret;
}
origin = NULL;
}
- /* Page mapping loop finished normally, nothing to clean up. */
- clean = 0;
ret:
- if (clean > 0) {
- /*
- * Something went wrong. Clean up shadow/origin pages allocated
- * on the last loop iteration, then delete mappings created
- * during the previous iterations.
- */
+ if (err) {
if (shadow)
- __free_pages(shadow, 1);
+ __free_pages(shadow, KMSAN_IOREMAP_META_ORDER);
if (origin)
- __free_pages(origin, 1);
- __vunmap_range_noflush(
- vmalloc_shadow(start),
- vmalloc_shadow(start + clean * PAGE_SIZE));
- __vunmap_range_noflush(
- vmalloc_origin(start),
- vmalloc_origin(start + clean * PAGE_SIZE));
+ __free_pages(origin, KMSAN_IOREMAP_META_ORDER);
+
+ if (mapped_end > start)
+ kmsan_iounmap_pages(start, mapped_end);
}
flush_cache_vmap(vmalloc_shadow(start), vmalloc_shadow(end));
flush_cache_vmap(vmalloc_origin(start), vmalloc_origin(end));
_
Patches currently in -mm which might be from dmytrokoziuk68@gmail.com are
reply other threads:[~2026-10-24 9:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261024090048.D4AD21F01828@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=dmytrokoziuk68@gmail.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=mm-commits@vger.kernel.org \
--cc=urezki@gmail.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