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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ