On Thu, 2023-01-05 at 09:03 +0100, Arnd Bergmann wrote: > On Thu, Jan 5, 2023, at 06:54, kernel test robot wrote: > > Greeting, > > > > FYI, we noticed BUG:kernel_NULL_pointer_dereference,address due to > > commit (built with clang-14): > > > > commit: aa0652d7f1b311e55232a8153522fdaaba0f197a ("tty: serial: handle > > HAS_IOPORT dependencies") > > https://git.kernel.org/cgit/linux/kernel/git/niks/linux.git > > has_ioport_v3 > > > > in testcase: boot > > > > on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G > > > > caused below changes (please refer to attached dmesg/kmsg for entire > > log/backtrace): > > > > > > [ 2.166733][ T0] calling univ8250_console_init+0x0/0x30 @ 0 > > [ 2.167555][ T0] BUG: kernel NULL pointer dereference, address: > > 00000000 > > I think it's this bit: > > @@ -508,12 +523,13 @@ static void set_io_from_upio(struct uart_port *p) > up->dl_read = au_serial_dl_read; > up->dl_write = au_serial_dl_write; > break; > -#endif > - > +#ifdef CONFIG_HAS_IOPORT > default: > p->serial_in = io_serial_in; > p->serial_out = io_serial_out; > break; > +#endif > +#endif > } > /* Remember loaded iotype */ > up->cur_iotype = p->iotype; > > > which puts the 'default' case inside of '#ifdef > CONFIG_SERIAL_8250_RT288X'. x86 does not use the > RT288x variant but relies on the default, so any > call to io_serial_{in,out} will cause a NULL > pointer dereference. > > Arnd Thanks for looking into it Arnd, your reasoning makes sense to me, I'll try to look into this and test this case before I sent out the v3 of the HAS_IOPORT patches. I still also have a few nitpicks from Bjorn, mostly about the commit messages, to work in. Hope to do that soon but got a few things going on at the moment.