Re: [PATCH 6 of 7] x86: use early_ioremap in __acpi_map_table

[Ingo Molnar <mingo@elte.hu>]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
> >> So i'd suggest a different, more carful approach: keep the new code 
> >> you wrote, but print a WARN()ing if prev_map is not unmapped yet when 
> >> the next mapping is acquired. That way the ACPI code can be fixed 
> >> gradually and without breaking existing functionality.
> >>     
> >
> > ok, i stuck in your patches into tip/master today and -tip testing 
> > quickly found an early-ioremap leak:
> >
> > [   36.625100] calling  check_early_ioremap_leak+0x0/0x3d
> > [   36.630253] ------------[ cut here ]------------
> > [   36.634884] WARNING: at arch/x86/mm/ioremap.c:577 check_early_ioremap_leak+0x28/0x3d()
> > [   36.642811] Debug warning: early ioremap leak of 1 areas detected.
> >
> > find the full log below with ioremap-leak-tracing turned on. I've 
> > excluded these commits for now from tip/master.
> >   
> 
> Yes, that leak is expected, unfortunately.  __acpi_map_table() has no 
> corresponding unmap, and only maintains one mapping.  So it will leak 
> its last mapping when it switches over from using __acpi_map_table() 
> to ioremap().
> 
> So, yes, its ugly, but its guaranteed to be a single leaked mapping. 
> But I'm not sure what the best approach to deal with it is.

the false positive should be avoided, for example by unmapping the 
'prev' mapping shortly before the leak check.

> (All those other backtraces are just informational, right?)

no, they cause hard failures in my test setup. Nor do we want to litter 
the bootup log with messages that are not correct.

	Ingo