linux-kernel - Re: [PATCH 6 of 7] x86: use early_ioremap in __acpi_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Sep 2008 09:33:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 6 of 7] x86: use early_ioremap in __acpi_map_table


* Jeremy Fitzhardinge <jeremy@...p.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/