[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1uTgFyPL+m2Ts3vigVc1V=BNLhMpF5UtJdnd+-FQy2_g@mail.gmail.com>
Date: Mon, 10 May 2021 15:47:29 +0200
From: Arnd Bergmann <arnd@...db.de>
To: kernel test robot <lkp@...el.com>
Cc: Niklas Schnelle <schnelle@...ux.ibm.com>,
Vineet Gupta <vgupta@...opsys.com>,
"David S. Miller" <davem@...emloft.net>, kbuild-all@...ts.01.org,
Networking <netdev@...r.kernel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
clang-built-linux <clang-built-linux@...glegroups.com>,
linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-s390 <linux-s390@...r.kernel.org>
Subject: Re: [PATCH v5 3/3] asm-generic/io.h: warn in inb() and friends with
undefined PCI_IOBASE
On Mon, May 10, 2021 at 3:08 PM kernel test robot <lkp@...el.com> wrote:
>
> In file included from include/linux/kernel.h:10,
> from drivers/media/rc/nuvoton-cir.c:25:
> include/linux/scatterlist.h: In function 'sg_set_buf':
> include/asm-generic/page.h:89:50: warning: ordered comparison of pointer with null pointer [-Wextra]
> 89 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void *)PAGE_OFFSET) && \
> | ^~
> include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
> 78 | # define unlikely(x) __builtin_expect(!!(x), 0)
> | ^
> include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
> 137 | BUG_ON(!virt_addr_valid(buf));
> | ^~~~~~
> include/linux/scatterlist.h:137:10: note: in expansion of macro 'virt_addr_valid'
> 137 | BUG_ON(!virt_addr_valid(buf));
> | ^~~~~~~~~~~~~~~
> drivers/media/rc/nuvoton-cir.c: In function 'nvt_get_rx_ir_data':
> >> drivers/media/rc/nuvoton-cir.c:761:15: warning: iteration 32 invokes undefined behavior [-Waggressive-loop-optimizations]
> 761 | nvt->buf[i] = nvt_cir_reg_read(nvt, CIR_SRXFIFO);
I think you can ignore this one, it's a preexisting issue with this
driver that gets uncovered by your patch: if "fifocount" is read from
a broken device as 0xff, the loop causes a buffer overflow.
The code is already unreachable because the interrupt handler
will have aborted already, so the compiler's dead code elimination
should have shut up that warning, but adding a range check
before the loop would address this as well.
As far as I can tell, this warning only shows up when building with
"make W=1".
Arnd
Powered by blists - more mailing lists