linux-kernel - Re: of/pci: Fix the conversion of IO ranges into IO resources

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, 16 Oct 2014 21:04:42 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Liviu Dudau <Liviu.Dudau@....com>
Cc:	Michael Ellerman <mpe@...erman.id.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-pci <linux-pci@...r.kernel.org>
Subject: Re: of/pci: Fix the conversion of IO ranges into IO resources

On Thu, 2014-10-16 at 10:05 +0100, Liviu Dudau wrote:
> So you are going to continue converting IO ranges as IORESOURCE_MEM resources but with a
> different flag. Is that something that powerpc depends on or is it an artifact of too
> much code living around the kernel that has built in assumption of that being the fact?
> I'm trying to understand the world around powerpc so as to attempt to make a useful
> contribution in the future.

I'm not sure I understand what you mean and which specific resources you
are talking about.

For PCI devices, the IO BAR resources have IORESOURCE_IO ... 

The case where we might get an IORESOURCE_MEM, at least that's how my old
code used to work, was is if we try to use the device-tree to convert a
PCI IO device address before we have initialized our mappings (ie, before
we have probed our PCI host bridges).

In that case, we would get an IORESOURCE_MEM (which is functional as long
as one ioremap's and uses the proper accessors for memory resources).

Once we have the PCI host bridges probed, the IO space is assigned, and
such conversion routines will transform the addresses properly into IO
resources.

Note that it's fairly rare that we use the device-tree for PCI based
resources anyway and even rarer than we do that before the PCI host
bridges have been properly setup and thus their IO space allocated.

Note that the problems exposed by these patches can be entirely reproduced
in qemu using virtio, so you should be able to test a little bit if you
have a reasonably fast x86 box to run qemu on.

Cheers,
Ben.

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