From: Hao Ge <hao.ge@linux.dev>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Uladzislau Rezki <urezki@gmail.com>, Dev Jain <dev.jain@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Alexander Potapenko <glider@google.com>,
Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@gentwo.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
stable@vger.kernel.org
Subject: Re: [PATCH v4 1/9] mm/kmsan: undo the shadow mapping when the origin mapping fails
Date: Thu, 12 Nov 2026 15:50:41 +0800 [thread overview]
Message-ID: <aa6caf61-a4a1-4c51-aae7-ebb767f3430c@linux.dev> (raw)
In-Reply-To: <CAJuCfpHjSZhPPpRudAdrDPzz8dGK=Mx62CYCNoO4MC9OhnGd=A@mail.gmail.com>
Hi Suren
On 2026/11/12 05:03, Suren Baghdasaryan wrote:
> On Tue, Nov 10, 2026 at 11:24 AM Hao Ge <hao.ge@linux.dev> wrote:
>>
>> kmsan_vmap_pages_range_noflush() first maps the shadow pages and then
>> the origin pages. If the second mapping fails, the first one is left
>> mapped, and the callers do not roll it back. The next vmap of the
>> same metadata range hits the stale PTEs again and fails with a
>> WARN_ON() and -EBUSY in vmap_pages_pte_range().
>>
>> Undo the shadow mapping on that error path, the same way
>> kmsan_ioremap_page_range() cleans up after a partial failure.
>> __vunmap_range_noflush() only clears the PTEs; nothing has touched
>> the shadow mapping, so no TLB flush is needed.
>>
>> Fixes: 47ebd0310e89 ("mm: kmsan: handle alloc failures in kmsan_vmap_pages_range_noflush()")
>> Cc: stable@vger.kernel.org
>> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
>> Reviewed-by: Dev Jain <dev.jain@arm.com>
>> Signed-off-by: Hao Ge <hao.ge@linux.dev>
>> ---
>> mm/kmsan/shadow.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
>> index 0c88d89bf0d6..2166086d3dc3 100644
>> --- a/mm/kmsan/shadow.c
>> +++ b/mm/kmsan/shadow.c
>> @@ -258,6 +258,10 @@ int kmsan_vmap_pages_range_noflush(unsigned long start, unsigned long end,
>> o_pages, page_shift);
>> kmsan_leave_runtime();
>> if (mapped) {
>> + /* Undo the shadow mapping set up above. */
>> + kmsan_enter_runtime();
>> + __vunmap_range_noflush(shadow_start, shadow_end);
>
> Sorry, there is a problem here. You introduce "can_resched" check to
> avoid calling cond_resched() later in the series (in patch #7), but at
> this point __vunmap_range_noflush() can be called with GFP flags which
> do not allow blocking. Before recent Ulad's change called "kmsan:
> remove hard-coded GFP_KERNEL flags" this function was called only with
> GPF_KERNEL but now that's not the case. I think you can move
> introduction of can_resched flag into this patch.
Agree. I just went back and looked at Ulad's b186a94227b7 ("kmsan:
remove hard-coded GFP_KERNEL flags").
So will do next version. But perhaps it is better to make it a separate
prep patch in the same series? Because besides this call site, the other
places that call __vunmap_range_noflush() need to be changed as well.
Thanks
Best Regards
Hao
>
>> + kmsan_leave_runtime();
>> err = mapped;
>> goto ret;
>> }
>> --
>> 2.25.1
>>
next prev parent reply other threads:[~2026-11-12 7:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 11:25 [PATCH v4 0/9] mm/vmalloc: fix up vmap error handling Hao Ge
2026-11-10 11:25 ` [PATCH v4 1/9] mm/kmsan: undo the shadow mapping when the origin mapping fails Hao Ge
2026-11-11 21:03 ` Suren Baghdasaryan
2026-11-12 7:50 ` Hao Ge [this message]
2026-11-12 15:50 ` Suren Baghdasaryan
2026-11-10 11:25 ` [PATCH v4 2/9] mm/kmsan: skip vunmap_range_noflush when KMSAN is disabled Hao Ge
2026-11-11 22:10 ` Suren Baghdasaryan
2026-11-12 7:32 ` Hao Ge
2026-11-10 11:25 ` [PATCH v4 3/9] mm/vmalloc: BUG_ON() on an unaligned range in vmap_range_noflush() Hao Ge
2026-11-10 12:28 ` Hao Ge
2026-11-12 0:00 ` Suren Baghdasaryan
2026-11-12 12:23 ` Uladzislau Rezki
2026-11-10 11:25 ` [PATCH v4 4/9] mm/vmalloc: BUG_ON() on an unaligned range in vmap_pages_range_noflush_walk() Hao Ge
2026-11-12 0:16 ` Suren Baghdasaryan
2026-11-12 7:22 ` Hao Ge
2026-11-12 12:11 ` Uladzislau Rezki
2026-11-10 11:25 ` [PATCH v4 5/9] mm/vmalloc: BUG_ON() on an unaligned range in __vunmap_range_noflush() Hao Ge
2026-11-12 0:22 ` Suren Baghdasaryan
2026-11-12 12:15 ` Uladzislau Rezki
2026-11-10 11:25 ` [PATCH v4 6/9] mm/vmalloc: only flush the cache after the vmap succeeded Hao Ge
2026-11-12 0:30 ` Suren Baghdasaryan
2026-11-12 7:01 ` Hao Ge
2026-11-12 12:16 ` Uladzislau Rezki
2026-11-10 11:25 ` [PATCH v4 7/9] mm/vmalloc: undo partial mappings inside the mapping functions Hao Ge
2026-11-12 1:15 ` Suren Baghdasaryan
2026-11-12 6:27 ` Hao Ge
2026-11-12 12:19 ` Uladzislau Rezki
2026-11-10 11:25 ` [PATCH v4 8/9] powerpc: drop redundant unmaps of failed vmap mappings Hao Ge
2026-11-10 11:25 ` [PATCH v4 9/9] mm/percpu: stop unmapping the CPU that failed to map Hao Ge
2026-11-11 20:45 ` [PATCH v4 0/9] mm/vmalloc: fix up vmap error handling Suren Baghdasaryan
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=aa6caf61-a4a1-4c51-aae7-ebb767f3430c@linux.dev \
--to=hao.ge@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=chleroy@kernel.org \
--cc=cl@gentwo.org \
--cc=dennis@kernel.org \
--cc=dev.jain@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=ritesh.list@gmail.com \
--cc=sshegde@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=tj@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 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.