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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ