linux-kernel - Re: powerpc: io-defs.h:43:1: error: performing pointer arithmetic on a null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]

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: <3d139886-9549-4384-918a-2d18480eb758@app.fastmail.com>
Date: Tue, 16 Apr 2024 13:01:40 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Naresh Kamboju" <naresh.kamboju@...aro.org>,
 "open list" <linux-kernel@...r.kernel.org>, lkft-triage@...ts.linaro.org,
 "Linux Regressions" <regressions@...ts.linux.dev>,
 linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Cc: "Anders Roxell" <anders.roxell@...aro.org>,
 "Dan Carpenter" <dan.carpenter@...aro.org>,
 clang-built-linux <llvm@...ts.linux.dev>,
 "Nathan Chancellor" <nathan@...nel.org>,
 "Nick Desaulniers" <ndesaulniers@...gle.com>,
 "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
 "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
 "Jeff Xu" <jeffxu@...omium.org>, "Kees Cook" <keescook@...omium.org>,
 "Niklas Schnelle" <schnelle@...ux.ibm.com>
Subject: Re: powerpc: io-defs.h:43:1: error: performing pointer arithmetic on a null
 pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]

On Tue, Apr 16, 2024, at 11:32, Naresh Kamboju wrote:
> The Powerpc clang builds failed due to following warnings / errors on the
> Linux next-20240416 tag.
>
> Powerpc:
>  - tqm8xx_defconfig + clang-17 - Failed
>  - allnoconfig + clang-17 - Failed
>  - tinyconfig + clang-17 - Failed
>
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>

I'm not sure why this showed up now, but there is a series from
in progress that will avoid this in the future, as the same
issue is present on a couple of other architectures.

The broken definitions are in the !CONFIG_PCI path of

#ifndef CONFIG_PCI
#define _IO_BASE        0
#define _ISA_MEM_BASE   0
#define PCI_DRAM_OFFSET 0
#elif defined(CONFIG_PPC32)
#define _IO_BASE        isa_io_base
#define _ISA_MEM_BASE   isa_mem_base
#define PCI_DRAM_OFFSET pci_dram_offset
#else
#define _IO_BASE        pci_io_base
#define _ISA_MEM_BASE   isa_mem_base
#define PCI_DRAM_OFFSET 0
#endif

Once the series is merged, the !PCI case can disable
CONFIG_HAS_IOPORT and move all references to it into #ifdef
sections, something like the (incomplete) patch below.

It looks like regardless of this, powerpc can also just set
_IO_BASE to ISA_IO_BASE unconditionally, but I could be missing
something there.

     Arnd

---
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 08c550ed49be..29e002b9316c 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -36,11 +36,8 @@ extern struct pci_dev *isa_bridge_pcidev;
  * bases. Most of this file only uses _IO_BASE though which we
  * define properly based on the platform
  */
-#ifndef CONFIG_PCI
-#define _IO_BASE	0
-#define _ISA_MEM_BASE	0
-#define PCI_DRAM_OFFSET 0
-#elif defined(CONFIG_PPC32)
+#ifdef CONFIG_HAS_IOPORT
+#ifdef CONFIG_PPC32
 #define _IO_BASE	isa_io_base
 #define _ISA_MEM_BASE	isa_mem_base
 #define PCI_DRAM_OFFSET	pci_dram_offset
@@ -486,8 +483,7 @@ static inline u64 __raw_rm_readq(volatile void __iomem *paddr)
  * to port it over
  */
 
-#ifdef CONFIG_PPC32
-
+#if defined(CONFIG_PPC32) && defined(CONFIG_HAS_IOPORT)
 #define __do_in_asm(name, op)				\
 static inline unsigned int name(unsigned int port)	\
 {							\
@@ -534,7 +530,7 @@ __do_out_asm(_rec_outb, "stbx")
 __do_out_asm(_rec_outw, "sthbrx")
 __do_out_asm(_rec_outl, "stwbrx")
 
-#endif /* CONFIG_PPC32 */
+#endif /* CONFIG_PPC32 && CONFIG_HAS_IOPORT */
 
 /* The "__do_*" operations below provide the actual "base" implementation
  * for each of the defined accessors. Some of them use the out_* functions
@@ -577,6 +573,7 @@ __do_out_asm(_rec_outl, "stwbrx")
 #define __do_readq_be(addr)	in_be64(PCI_FIX_ADDR(addr))
 #endif /* !defined(CONFIG_EEH) */
 
+#ifdef CONFIG_HAS_IOPORT
 #ifdef CONFIG_PPC32
 #define __do_outb(val, port)	_rec_outb(val, port)
 #define __do_outw(val, port)	_rec_outw(val, port)
@@ -592,6 +589,7 @@ __do_out_asm(_rec_outl, "stwbrx")
 #define __do_inw(port)		readw((PCI_IO_ADDR)_IO_BASE + port);
 #define __do_inl(port)		readl((PCI_IO_ADDR)_IO_BASE + port);
 #endif /* !CONFIG_PPC32 */
+#endif
 
 #ifdef CONFIG_EEH
 #define __do_readsb(a, b, n)	eeh_readsb(PCI_FIX_ADDR(a), (b), (n))
@@ -606,12 +604,14 @@ __do_out_asm(_rec_outl, "stwbrx")
 #define __do_writesw(a, b, n)	_outsw(PCI_FIX_ADDR(a),(b),(n))
 #define __do_writesl(a, b, n)	_outsl(PCI_FIX_ADDR(a),(b),(n))
 
+#ifdef CONFIG_HAS_IOPORT
 #define __do_insb(p, b, n)	readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
 #define __do_insw(p, b, n)	readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
 #define __do_insl(p, b, n)	readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
 #define __do_outsb(p, b, n)	writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
 #define __do_outsw(p, b, n)	writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
 #define __do_outsl(p, b, n)	writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
+#endif
 
 #define __do_memset_io(addr, c, n)	\
 				_memset_io(PCI_FIX_ADDR(addr), c, n)
@@ -689,6 +689,8 @@ static inline void name at					\
 #define writesb writesb
 #define writesw writesw
 #define writesl writesl
+
+#ifdef CONFIG_HAS_IOPORT
 #define inb inb
 #define inw inw
 #define inl inl
@@ -701,6 +703,8 @@ static inline void name at					\
 #define outsb outsb
 #define outsw outsw
 #define outsl outsl
+#endif
+
 #ifdef __powerpc64__
 #define readq	readq
 #define writeq	writeq