All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Frans Pop <elendil@planet.nl>, Eric Anholt <eric@anholt.net>,
	nix.or.die@googlemail.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, Arjan van de Ven <arjan@infradead.org>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: Linux 2.6.28-rc8
Date: Thu, 11 Dec 2008 21:36:04 +0100	[thread overview]
Message-ID: <20081211203604.GA14817@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.0812110902450.3340@localhost.localdomain>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 11 Dec 2008, Ingo Molnar wrote:
> > 
> > hm, the warning caught a couple of real bugs already. (one in some 
> > cpq driver, another was in some networking driver iirc)
> 
> Well, one thing that does irritate me is that it scares people who 
> can't do anything about it, and probably _shouldn't_ do anything about 
> it.

yeah - and false positives also tend to create apathy and resistence 
against kernel warnings - thus drawing tester resources away from more 
important bugs.

> I wonder if we should just change the "Warning" message to 
> "Informational" or something. Yes, they are often real bugs. But no, 
> they're not _automatically_ bugs. Almost all the time when a warning 
> triggers, it's really just a developer who wants to know about it, it's 
> not something that a user should really care/worry about.

ok. In this case i'd suggest we should just remove the warning. People do 
get scared by needless kernel stack dumps - no matter whether it's marked 
informational or not.

So how about the patch below, queued up in tip/x86/debug? Arjan, what do 
you think?

	Ingo

--------------->
>From 2dcae81e819fa5cc0e9310ef8b0c079940df3bf3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 11 Dec 2008 21:29:51 +0100
Subject: [PATCH] IO resources, x86: remove multi-BAR mapping sanity check

Impact: remove a debug warning

The ioremap() time multi-BAR map warning has been causing false positives:

 http://lkml.org/lkml/2008/12/10/432
 http://lkml.org/lkml/2008/12/11/136

So remove it for now.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/mm/ioremap.c  |    6 ------
 include/linux/ioport.h |    1 -
 kernel/resource.c      |   38 --------------------------------------
 3 files changed, 0 insertions(+), 45 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..421b92d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -220,12 +220,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 		return (__force void __iomem *)phys_to_virt(phys_addr);
 
 	/*
-	 * Check if the request spans more than any BAR in the iomem resource
-	 * tree.
-	 */
-	WARN_ON(iomem_map_sanity_check(phys_addr, size));
-
-	/*
 	 * Don't allow anybody to remap normal RAM that we're using..
 	 */
 	for (pfn = phys_addr >> PAGE_SHIFT;
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 041e95a..0dde772 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -174,7 +174,6 @@ extern struct resource * __devm_request_region(struct device *dev,
 
 extern void __devm_release_region(struct device *dev, struct resource *parent,
 				  resource_size_t start, resource_size_t n);
-extern int iomem_map_sanity_check(resource_size_t addr, unsigned long size);
 
 #endif /* __ASSEMBLY__ */
 #endif	/* _LINUX_IOPORT_H */
diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..4b0bc70 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -829,41 +829,3 @@ static int __init reserve_setup(char *str)
 }
 
 __setup("reserve=", reserve_setup);
-
-/*
- * Check if the requested addr and size spans more than any slot in the
- * iomem resource tree.
- */
-int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
-{
-	struct resource *p = &iomem_resource;
-	int err = 0;
-	loff_t l;
-
-	read_lock(&resource_lock);
-	for (p = p->child; p ; p = r_next(NULL, p, &l)) {
-		/*
-		 * We can probably skip the resources without
-		 * IORESOURCE_IO attribute?
-		 */
-		if (p->start >= addr + size)
-			continue;
-		if (p->end < addr)
-			continue;
-		if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
-		    PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
-			continue;
-		printk(KERN_WARNING "resource map sanity check conflict: "
-		       "0x%llx 0x%llx 0x%llx 0x%llx %s\n",
-		       (unsigned long long)addr,
-		       (unsigned long long)(addr + size - 1),
-		       (unsigned long long)p->start,
-		       (unsigned long long)p->end,
-		       p->name);
-		err = -1;
-		break;
-	}
-	read_unlock(&resource_lock);
-
-	return err;
-}

  reply	other threads:[~2008-12-11 20:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11  1:04 Linux 2.6.28-rc8 Linus Torvalds
2008-12-11  2:37 ` Gabriel C
2008-12-11  7:19   ` Eric Anholt
2008-12-11 16:07     ` Frans Pop
2008-12-11 16:22       ` Linus Torvalds
2008-12-11 16:35         ` Ingo Molnar
2008-12-11 17:05           ` Linus Torvalds
2008-12-11 20:36             ` Ingo Molnar [this message]
2008-12-11 20:46               ` Pekka Enberg
2008-12-11 21:34                 ` Suresh Siddha
2008-12-12  8:24                 ` Ingo Molnar
2008-12-12 15:57                   ` Arjan van de Ven
2008-12-12 16:11                     ` Linus Torvalds
2008-12-13 17:15                       ` Arjan van de Ven
2008-12-16 22:34                         ` Ingo Molnar
2008-12-11  5:09 ` Arjan van de Ven
2008-12-11  7:57 ` Nick Piggin
2008-12-11  8:07   ` Andrew Morton
2008-12-11  8:45     ` Nick Piggin
2008-12-12  3:02       ` Andrew Morton
2008-12-12  3:07         ` Nick Piggin
2008-12-12  3:39           ` Andrew Morton
2008-12-11  8:06 ` Willy Tarreau
2008-12-11  8:40 ` Joerg Roedel
2008-12-11 22:57   ` Theodore Tso
2008-12-11 23:12     ` Mike Travis
2008-12-11  9:26 ` Jean Delvare
2008-12-11 10:38 ` Frederik Deweerdt
2008-12-11 16:59   ` Andrew Morton
2008-12-11 13:00 ` Sam Ravnborg
2008-12-11 13:23   ` Paolo Ciarrocchi
2008-12-11 13:44 ` Alexey Zaytsev
2008-12-11 13:48 ` Ingo Molnar
2008-12-11 15:20 ` Pavel Machek
2008-12-11 15:29 ` David Howells
2008-12-12  3:19   ` David Miller
2008-12-12  5:40     ` Linus Torvalds
2008-12-12  7:54       ` Joerg Roedel
2008-12-12 15:48     ` Alan Cox
2008-12-11 20:12 ` Rafael J. Wysocki

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=20081211203604.GA14817@elte.hu \
    --to=mingo@elte.hu \
    --cc=arjan@infradead.org \
    --cc=elendil@planet.nl \
    --cc=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nix.or.die@googlemail.com \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /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.