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
| ||
|
Date: Thu, 5 May 2022 09:45:14 +0100 (BST) From: "Maciej W. Rozycki" <macro@...am.me.uk> To: Bjorn Helgaas <helgaas@...nel.org> cc: Arnd Bergmann <arnd@...nel.org>, Niklas Schnelle <schnelle@...ux.ibm.com>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>, linux-pci <linux-pci@...r.kernel.org>, Dominik Brodowski <linux@...inikbrodowski.net> Subject: Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies On Wed, 4 May 2022, Bjorn Helgaas wrote: > > Well, yes, except I would expect POWER9_CPU (and any higher versions we > > eventually get) to clear HAS_IOPORT. Generic configurations (GENERIC_CPU) > > would set HAS_IOPORT of course, as would any lower architecture variants > > that do or may support port I/O (it's not clear to me if there are any > > that do not). Ideally a generic configuration would not issue accesses to > > random MMIO locations for port I/O accesses via `inb'/`outb', etc. for > > systems that do not support port I/O (which it now does, or at least used > > to until recently). > > It would seem weird to me that a module would build and run on a > generic kernel running on POWER9 (with some safe way of handling > inb/outb that don't actually work), but not on a kernel built > specifically for POWER9_CPU. Why? If you say configure your Alpha kernel for ALPHA_JENSEN, a pure EISA system, then you won't get PCI support nor any PCI drivers offered even though a generic Alpha kernel will get them all and still run on a Jensen system. I find that no different from our case here. And if we do ever get TURBOchannel Alpha support, then a generic kernel configuration will offer EISA, PCI and TURBOchannel drivers, while you won't be offered TURBOchannel drivers for a PCI system and vice versa. It would make no sense to me. Please mind that the main objective for system-specific configurations is optimisation, including both size and speed, and a part of the solution is discarding stuff that's irrelevant for the respective system. So in our case we do want any port I/O code not to be there at all in compiled code and consequently any driver that absolutely requires port I/O code to work will have to become a useless stub in its compiled form. What would be the point then of having it there in the first place except to spread confusion? Maciej
Powered by blists - more mailing lists