linux-kernel - Re: pci_fixup_video change blows up on sparc64

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: <20061019.153228.39159105.davem@davemloft.net>
Date:	Thu, 19 Oct 2006 15:32:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eiichiro.oiwa.nm@...achi.com
Cc:	alan@...hat.com, jesse.barnes@...el.com, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: pci_fixup_video change blows up on sparc64

From: <eiichiro.oiwa.nm@...achi.com>
Date: Thu, 19 Oct 2006 19:49:26 +0900

> The "0xc0000" is a physical address. The BAR (PCI base address) is also
> a physcail address. There are no difference.

Your assertion that the BAR is a physical address is very platform
specific.  It may be a "physical address in PCI bus space", but
that has no relation to the first argument passed to ioremap()
which is defined in a completely different way.

On many platforms, the BAR of PCI devices are translated into an
appropriate "ioremap() cookie" in the struct pci_dev resource[] array
entries, so that they can be used properly as the first argument to
ioremap().  Only address cookies properly setup by the platform may be
legally passed into ioremap() as the first argument.  No such setups
are being made on this raw 0xc0000 address.

So, as you can see, I/O port and I/O memory space work differently on
different platforms and this abstraction of the first argument to
ioremap() is how we provide support for such differences.

If you try to access 0xc0000 via ioremap() on sparc64, it is going to
try and access that area non-cacheable which, since 0xc0000 is
physical RAM, will result in a BUS ERROR and a crash.

This physical location might be the area for the video ROM on x86,
x86_64, and perhaps even IA64, but it certainly is not used this way
on sparc64 systems.

I really would like to see this regression fixed, or at the very
least this code protected by X86, X86_64, IA64 conditionals.
-
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/