linux-kernel - Re: Linux 2.6.28-rc8

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: <alpine.LFD.2.00.0812110814360.3340@localhost.localdomain>
Date:	Thu, 11 Dec 2008 08:22:21 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Frans Pop <elendil@...net.nl>
cc:	Eric Anholt <eric@...olt.net>, nix.or.die@...glemail.com,
	linux-kernel@...r.kernel.org, rjw@...k.pl
Subject: Re: Linux 2.6.28-rc8

On Thu, 11 Dec 2008, Frans Pop wrote:

> Eric Anholt wrote:
> > My recommended solution, of course, is to remove vesafb.
> 
> How is taking away useful functionality from users a better option than 
> just fixing the bug?

Well, just to clarify: it's not a _bug_. It's a benign warnign that two 
subsystems are trying to map the same memory differently.

In this case, we have:

	resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb

and what it means is that the caller (which is i915_gem_entervt_ioctl) is 
trying to apparently ioremap the _whole_ graphics card MMIO resource 
(0xd0000000-0xdfffffff), but the vesafb driver has already registered the 
fact that it uses _part_ of that resource (0xd0000000-0xd07effff).

There's no bug there. It's a warning. It's usually a very odd situation 
when somebody tries to ioremap something that crosses resource reservation 
boundaries, but the thing is, in this case it's not really a problem.

It's triggered by a couple of oddities:

 - fbcon (vesafb) is odd and only requests a partial resource, because it 
   only uses part of the MMIO window.

 - the interaction between fbcon and X is odd to begin with, since they 
   both use the same physical resource.

so it's a generic warning that triggers because these things _shouldn't_ 
happen, but it's not actually an error in this case. We could just remove 
the warning. Or leave it in, in case it finds other (real) issues, and 
just ignore it.

		Linus
--
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/