[v4,5/5] serial/8250: Only use fifo after the port is initialized in console_write

The serial driver set the value of uart_8250_port.fcr in the function
serial8250_config_port, but only writes the value to the controller
register later in the initalization code.

That opens a small window in which is not safe to use the fifo for
console write.

Make sure the port is initialized correctly before reading the FCR
cached value.

Unfortunately, I lost track of who originally reported the issue. If
s/he is reading this, please speak up so I can give you the due credit.

Signed-off-by: Wander Lairson Costa <wander@redhat.com>
---
 drivers/tty/serial/8250/8250_port.c | 1 +
 1 file changed, 1 insertion(+)

On 16. 03. 22, 15:36, Wander Lairson Costa wrote:
> The serial driver set the value of uart_8250_port.fcr in the function
> serial8250_config_port, but only writes the value to the controller
> register later in the initalization code.
> 
> That opens a small window in which is not safe to use the fifo for
> console write.
> 
> Make sure the port is initialized correctly before reading the FCR
> cached value.
> 
> Unfortunately, I lost track of who originally reported the issue. If
> s/he is reading this, please speak up so I can give you the due credit.
> 
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> ---
>   drivers/tty/serial/8250/8250_port.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 4acf620be241..7e2227161555 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -3416,6 +3416,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
>   		!(up->capabilities & UART_CAP_MINI) &&
>   		up->tx_loadsz > 1 &&
>   		(up->fcr & UART_FCR_ENABLE_FIFO) &&
> +		test_bit(TTY_PORT_INITIALIZED, &port->state->port.iflags) &&

Cannot be port->state be NULL sometimes here?

>   		/*
>   		 * After we put a data in the fifo, the controller will send
>   		 * it regardless of the CTS state. Therefore, only use fifo

On Wed, 16 Mar 2022, Wander Lairson Costa wrote:

> The serial driver set the value of uart_8250_port.fcr in the function
> serial8250_config_port, but only writes the value to the controller
> register later in the initalization code.
> 
> That opens a small window in which is not safe to use the fifo for
> console write.
> 
> Make sure the port is initialized correctly before reading the FCR
> cached value.
> 
> Unfortunately, I lost track of who originally reported the issue. If
> s/he is reading this, please speak up so I can give you the due credit.
> 
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> ---
>  drivers/tty/serial/8250/8250_port.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 4acf620be241..7e2227161555 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -3416,6 +3416,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
>  		!(up->capabilities & UART_CAP_MINI) &&
>  		up->tx_loadsz > 1 &&
>  		(up->fcr & UART_FCR_ENABLE_FIFO) &&
> +		test_bit(TTY_PORT_INITIALIZED, &port->state->port.iflags) &&
>  		/*
>  		 * After we put a data in the fifo, the controller will send
>  		 * it regardless of the CTS state. Therefore, only use fifo

So it looks like 2-5 just contain your development history and should all 
be merged to 1/5 (perhaps with Co-developed-by: tags where appropriate).

And please don't just merge them "silently" there w/o describing in the 
message _why_ you ended up doing the things the way you did in the end.
The messages you've written for patches 2-5 will serve you as great source 
material (with small mods, obviously).

On Thu, Mar 17, 2022 at 5:44 AM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Wed, 16 Mar 2022, Wander Lairson Costa wrote:
>
> > The serial driver set the value of uart_8250_port.fcr in the function
> > serial8250_config_port, but only writes the value to the controller
> > register later in the initalization code.
> >
> > That opens a small window in which is not safe to use the fifo for
> > console write.
> >
> > Make sure the port is initialized correctly before reading the FCR
> > cached value.
> >
> > Unfortunately, I lost track of who originally reported the issue. If
> > s/he is reading this, please speak up so I can give you the due credit.
> >
> > Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> > ---
> >  drivers/tty/serial/8250/8250_port.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> > index 4acf620be241..7e2227161555 100644
> > --- a/drivers/tty/serial/8250/8250_port.c
> > +++ b/drivers/tty/serial/8250/8250_port.c
> > @@ -3416,6 +3416,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
> >               !(up->capabilities & UART_CAP_MINI) &&
> >               up->tx_loadsz > 1 &&
> >               (up->fcr & UART_FCR_ENABLE_FIFO) &&
> > +             test_bit(TTY_PORT_INITIALIZED, &port->state->port.iflags) &&
> >               /*
> >                * After we put a data in the fifo, the controller will send
> >                * it regardless of the CTS state. Therefore, only use fifo
>
> So it looks like 2-5 just contain your development history and should all
> be merged to 1/5 (perhaps with Co-developed-by: tags where appropriate).
>
> And please don't just merge them "silently" there w/o describing in the
> message _why_ you ended up doing the things the way you did in the end.
> The messages you've written for patches 2-5 will serve you as great source
> material (with small mods, obviously).
>

Ok, I will merge them in v5.

>
> --
>  i.
>