linux-kernel - Re: [PATCH] lib/devres.c: allow specifying NO

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: <1616727.0BYPKXtoA0@wuerfel>
Date:	Thu, 01 Dec 2011 23:47:43 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Chris Metcalf <cmetcalf@...era.com>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-arch@...r.kernel.org, Rolf Eike Beer <eike-kernel@...tec.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Maxin B. John" <maxin.john@...il.com>, Tejun Heo <tj@...nel.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
	Paul Mundt <lethal@...ux-sh.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] lib/devres.c: allow specifying NO_IOPORT while using PCI

On Thursday 01 December 2011 12:59:19 Chris Metcalf wrote:
> The tile architecture does not support IOPORT, but it does support
> PCI and IOMEM.  We were not specifying NO_IOPORT, though, because it
> was causing a couple of functions (pcim_iomap_regions and pcim_iomap_table)
> that are needed to not get provided.  Moving the #ifdef fixes this
> so that those functions and some related ones are now always provided
> if CONFIG_PCI is true.
> 
> Signed-off-by: Chris Metcalf <cmetcalf@...era.com>

Hmm, I'm sure that Al Viro intentionally did it the way it is, but I'm
not sure exactly why that would be.

Any driver using the functions you now expose for NO_IOPORT is probably
prepared to handle both MMIO and PIO BARs on PCI, which you can consider
broken in the case where a card actually requires PIO.

On tile, it would be just as broken as other drivers that directly use
inb/outb to do the port access, but on platforms that actually have
PIO but are not able to map them (like arm/mach-rpc), you would now
enable people to write silently broken drivers.

However, assuming they check the return value of the *iomap, the
drivers could still easily detect this case at runtime. Also, at
least on tile, you already provide a pci_iomap function, which
has the exact same problem as the devres functions.

One area where your patch might actually break existing code is
architectures that allow the devres functions to be built *and*
have PCI support but don't provide a pci_iomap function, because
they do not support mapping the PIO range into addresses. I'm
not sure if that's actually still the case anywhere after Michael's
recent patches, but it used to be the case on RPC and probably others.

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