linux-kernel - [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation

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]

Message-Id: <200907240953.48297.elendil@planet.nl>
Date:	Fri, 24 Jul 2009 09:53:47 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation

On Thursday 23 July 2009, Linus Torvalds wrote:
> On Thu, 23 Jul 2009, Frans Pop wrote:
> > On Thursday 23 July 2009, Frans Pop wrote:
> > > I'm seeing the following change in dmesg between -rc3 and -rc4:
> > > -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> > > +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
> > >
> > > There is nothing in the earlier part of dmesg that would explain
> > > this change.
> >
> > Reverting that commit did indeed restore the old situation.
>
> So think of it this way: the difference between "has been reserved" and
> "could not be reserved" is _not_ a "good" vs "bad" situation. They are
> both purely informational. They're not good-or-bad, they are
> information we leave around in case bad things happen later.

Yeah, I suspected that might be the case (which is why I used "restores old
situation" rather than "fixes regression" :-). My message was triggered by
the fact that it's still a somewhat unusual change, so I was mainly looking
for confirmation that it was intended.

Still, failure messages can be confusing for users. The source code documents
that reservation failures are expected, but most users don't read source...

So, also looking at David John's message, would something like the patch
below be an option? The result is as follows on my system:

pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: iomem range 0x0-0x9ffff could not be reserved
(The fact that a range could not be reserved is generally harmless.)
system 00:00: iomem range 0xe0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
system 00:0a: ioport range 0x500-0x55f has been reserved

---
From: Frans Pop <elendil@...net.nl>
Subject: PNP: make explicit that range allocation failures are generally harmless

Signed-off-by: Frans Pop <elendil@...net.nl>

diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..72de2a7 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -52,6 +52,10 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t 
start,
 		port ? "ioport" : "iomem",
 		(unsigned long long) start, (unsigned long long) end,
 		res ? "has been" : "could not be");
+	if (!res)
+		printk_once(KERN_INFO
+			"(The fact that a range could not be reserved "
+			"is generally harmless.)\n");
 }
 
 static void reserve_resources_of_dev(struct pnp_dev *dev)
--
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/