Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5f6a4b1e0a5a85f6e2e9f674bc88843c5ab623c6.camel@linux.ibm.com>
Subject: Re: [niks:has_ioport_v3] [tty] aa0652d7f1:
 BUG:kernel_NULL_pointer_dereference,address
From:   Niklas Schnelle <schnelle@linux.ibm.com>
To:     Arnd Bergmann <arnd@kernel.org>,
        kernel test robot <yujie.liu@intel.com>
Cc:     oe-lkp@lists.linux.dev, kernel test robot <lkp@intel.com>,
        linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Date:   Mon, 09 Jan 2023 09:45:04 +0100
In-Reply-To: <e211f932-77c3-427a-859a-d846598524ed@app.fastmail.com>
References: <202301051008.a8468257-yujie.liu@intel.com>
         <e211f932-77c3-427a-859a-d846598524ed@app.fastmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.46.2 (3.46.2-1.fc37) 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

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,
> >=20
> > FYI, we noticed BUG:kernel_NULL_pointer_dereference,address due to=20
> > commit (built with clang-14):
> >=20
> > commit: aa0652d7f1b311e55232a8153522fdaaba0f197a ("tty: serial: handle=
=20
> > HAS_IOPORT dependencies")
> > https://git.kernel.org/cgit/linux/kernel/git/niks/linux.git=20
> > has_ioport_v3
> >=20
> > in testcase: boot
> >=20
> > on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -=
m 4G
> >=20
> > caused below changes (please refer to attached dmesg/kmsg for entire=20
> > log/backtrace):
> >=20
> >=20
> > [    2.166733][    T0] calling  univ8250_console_init+0x0/0x30 @ 0
> > [    2.167555][    T0] BUG: kernel NULL pointer dereference, address:=20
> > 00000000
>=20
> I think it's this bit:
>=20
> @@ -508,12 +523,13 @@ static void set_io_from_upio(struct uart_port *p)
>                 up->dl_read =3D au_serial_dl_read;
>                 up->dl_write =3D au_serial_dl_write;
>                 break;
> -#endif
> -
> +#ifdef CONFIG_HAS_IOPORT
>         default:
>                 p->serial_in =3D io_serial_in;
>                 p->serial_out =3D io_serial_out;
>                 break;
> +#endif
> +#endif
>         }
>         /* Remember loaded iotype */
>         up->cur_iotype =3D p->iotype;
>=20
>=20
> 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.
>=20
>        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.