linux-kernel - Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 2 Mar 2008 16:53:48 +0100
From:	Fabio Checconi <fchecconi@...il.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Gabriel C <nix.or.die@...glemail.com>,
	Laurent Riffard <laurent.riffard@...e.fr>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Stuart Bennett <sb476@....ac.uk>,
	Len Brown <lenb@...nel.org>, tglx@...utronix.de,
	mingo@...hat.com
Subject: Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129

[cc'd relevant maintainers]

Hi,

> From: Arjan van de Ven <arjan@...ux.intel.com>
> Date: Mon, Feb 25, 2008 02:44:53PM -0800
>
> Gabriel C wrote:
...
> >With your patch from 
> >http://marc.info/?l=linux-kernel&m=120336371506283&w=2 I don't have a 
> >warning anymore.
> >
> 
> that is ... odd since it's the same in theory, just with some added 
> printk's ;-(

the same here on 2.6.25-rc3, with the innocent ibmphp_access_ebda()
that fires the WARN_ON() in __ioremap() asking for the pfn 0, even
after the page_is_ram() change.  With your patch the warning
disappears.

I think this is because the pfn checked by the original code (before
your patch) is the one after the last iteration, while your patch
checks for each pfn that is going to be mapped.  The latter should
be the intended behavior.  If I've understood the problem, the
(trivial) patch below should fix it.

Also, note that if last_addr is at the beginning of a page we can
__ioremap() normal RAM (in fact we only emit the warning with the
old code, instead of returning NULL.)  Is that possible/intended
behavior?  If not the loop should do one more iteration.

__ioremap() emits a warning if the pfn after the last one it's going
to map is of normal ram.  Correct this and emit the warning (once)
only if one of the asked pages is.

Signed-off-by: Fabio Checconi <fabio@...dalf.sssup.it>
---
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index ac3c959..6f7b158 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -109,7 +109,7 @@ static int ioremap_change_attr(unsigned long vaddr, unsigned long size,
 static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
 			       enum ioremap_mode mode)
 {
-	unsigned long pfn, offset, last_addr, vaddr;
+	unsigned long pfn, offset, last_addr, vaddr, is_ram = 0;
 	struct vm_struct *area;
 	pgprot_t prot;

@@ -132,9 +132,10 @@ static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
 		if (page_is_ram(pfn) && pfn_valid(pfn) &&
 		    !PageReserved(pfn_to_page(pfn)))
 			return NULL;
+		is_ram |= page_is_ram(pfn);
 	}

-	WARN_ON_ONCE(page_is_ram(pfn));
+	WARN_ON_ONCE(is_ram);

 	switch (mode) {
 	case IOR_MODE_UNCACHED:
--
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/