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;
-}
next prev parent 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.