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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Aug 2021 10:19:12 +0100 From: John Garry <john.garry@...wei.com> To: Arnd Bergmann <arnd@...nel.org> CC: Linus Torvalds <torvalds@...ux-foundation.org>, linux-arch <linux-arch@...r.kernel.org>, linux-pci <linux-pci@...r.kernel.org>, "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>, Niklas Schnelle <schnelle@...ux.ibm.com> Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access On 04/08/2021 09:52, Arnd Bergmann wrote: >>>> On another point, I noticed SCSI driver AHA152x depends on ISA, but is >>>> not an isa driver - however it does use port IO. Would such dependencies >>>> need to be changed to depend on HAS_IOPORT? >>> I'm not sure what you mean here. As far as I can tell, AHA152x is an ISA >>> driver in the sense that it is a driver for ISA add-on cards. However, it >>> is not a 'struct isa_driver' in the sense that AHA1542 is, AHA152x is even >>> older and uses the linux-2.4 style initialization using a module_init() >>> function that does the probing. >> ok, fine. So I just wonder what the ISA kconfig dependency gets us for >> aha152x. I experimented by removing the kconfig dependency and enabling >> for the arm64 (which does not have CONFIG_ISA) std defconfig and it >> built fine. > The point of CONFIG_ISA is to only build drivers for ISA add-on cards > on architectures that can have such slots. For ISA drivers in particular, > we don't want them to be loaded on machines that don't have them > because of the various ways this can cause trouble with hardwired > port and irq numbers. > >>>> Yeah, that sounds the same as what I was thinking. Maybe IOPORT_NATIVE >>>> could work as a name. I would think that only x86/ia64 would define it. >>>> A concern though is that someone could argue that is a functional >>>> dependency, rather than just a build dependency. >>> You can have those on a number of platforms, such as early >>> PowerPC CHRP or pSeries systems, a number of MIPS workstations >>> including recent Loongson machines, and many Alpha platforms. >>> >> hmmm... if some machines under an arch support "native" port IO and some >> don't, then if we use a common multi-platform defconfig which defines >> HARDCODED_IOPORT, then we still build for platforms without "native" >> port IO, which is not ideal. > Correct, but that's not a problem I'm trying to solve at this point. The > machines that have those are extremely rare, so almost all configurations > that one would encounter in practice do not suffer from it, and solving it > reliably would be really hard. Hi Arnd, This seems a reasonable approach. Do you have a plan for this work? Or still waiting for the green light? I have noticed the kernel test robot reporting the following to me, which seems to be the same issue which was addressed in this series originally: config: s390-randconfig-r032-20210802 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 4f71f59bf3d9914188a11d0c41bedbb339d36ff5) ... All errors (new ones prefixed by >>): In file included from drivers/block/null_blk/main.c:12: In file included from drivers/block/null_blk/null_blk.h:8: In file included from include/linux/blkdev.h:25: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:464:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); So I imagine lots of people are seeing these. Thanks, john
Powered by blists - more mailing lists