Re: [PATCH 1/2] mm: kmsan: fix iounmap metadata teardown

[Andrew Morton]

On Mon, 28 Sep 2026 19:55:22 +0300 Dmytro Koziuk <dmytrokoziuk68@xxxxxxxxx> wrote:

> Hi Andrew,
> 
> Just a gentle ping on this. Is there anything else I should address?

I was awaiting maintainer review before taking any action.

Folks, could you please take a look at these memory-leak fixes?

> Thanks,
> Dima
> 
> ср, 16 сент. 2026 г. в 10:22, Dmytro Koziuk <dmytrokoziuk68@xxxxxxxxx>:
> >
> > >  AI review might have a found a couple of issues - please check?
> >
> > I don't think the patch needs to be changed for these issues. For
> > normal iounmap(), the
> > caller must ensure that the mapping is no longer in use. Also,
> > the x86 implementation keeps the virtual range reserved until after
> > kmsan_iounmap_page_range() returns and its TLB flush completes.
> >
> > For the kmsan_ioremap_page_range() error path, the mapping has not yet
> > been returned to the caller. Cleanup and the TLB flush complete before
> > the reserved virtual range is released.
> >
> >
> > ср, 16 сент. 2026 г. в 01:35, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:
> > >
> > > On Tue, 15 Sep 2026 19:02:06 +0300 Dima Koziuk <dmytrokoziuk68@xxxxxxxxx> wrote:
> > >
> > > > While studying the code, I noticed that kmsan_iounmap_page_range() calls
> > > > __vunmap_range_noflush(v_shadow, vmalloc_shadow(end)) inside its per-page
> > > > loop, and does the same for origin. The first iteration therefore unmaps
> > > > the entire metadata range, removing the PTEs for later pages before the
> > > > loop can recover their backing pages.
> > >
> > > Thanks.
> > >
> > > AI review might have a found a couple of issues - please check?
> > >
> > > https://sashiko.dev/#/patchset/20260915160207.2952-1-dmytrokoziuk68@xxxxxxxxx