From: Jiri Slaby <jirislaby@kernel.org>
To: John Ogness <john.ogness@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Neil Armstrong <narmstrong@baylibre.com>,
Kevin Hilman <khilman@baylibre.com>
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v1] serial: meson: acquire port->lock in startup()
Date: Mon, 9 May 2022 07:42:12 +0200 [thread overview]
Message-ID: <c0eac83f-8483-7709-b558-561ff7a382b0@kernel.org> (raw)
In-Reply-To: <20220508103547.626355-1-john.ogness@linutronix.de>
On 08. 05. 22, 12:35, John Ogness wrote:
> The uart_ops startup() callback is called without interrupts
> disabled and without port->lock locked, relatively late during the
> boot process (from the call path of console_on_rootfs()). If the
> device is a console, it was already previously registered and could
> be actively printing messages.
>
> Since the startup() callback is reading/writing registers used by
> the console write() callback (AML_UART_CONTROL), its access must
> be synchronized using the port->lock. Currently it is not.
>
> The startup() callback is the only function that explicitly enables
> interrupts. Without the synchronization, it is possible that
> interrupts become accidentally permanently disabled.
>
> CPU0 CPU1
> meson_serial_console_write meson_uart_startup
> -------------------------- ------------------
> spin_lock(port->lock)
> val = readl(AML_UART_CONTROL)
> uart_console_write()
> writel(INT_EN, AML_UART_CONTROL)
> writel(val, AML_UART_CONTROL)
> spin_unlock(port->lock)
>
> Add port->lock synchronization to meson_uart_startup() to avoid
> racing with meson_serial_console_write().
>
> Also add detailed comments to meson_uart_reset() explaining why it
> is *not* using port->lock synchronization.
>
> Link: https://lore.kernel.org/lkml/2a82eae7-a256-f70c-fd82-4e510750906e@samsung.com
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Makes sense to me.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
> ---
> drivers/tty/serial/meson_uart.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index 2bf1c57e0981..39021dac09cc 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -253,6 +253,14 @@ static const char *meson_uart_type(struct uart_port *port)
> return (port->type == PORT_MESON) ? "meson_uart" : NULL;
> }
>
> +/*
> + * This function is called only from probe() using a temporary io mapping
> + * in order to perform a reset before setting up the device. Since the
> + * temporarily mapped region was successfully requested, there can be no
> + * console on this port at this time. Hence it is not necessary for this
> + * function to acquire the port->lock. (Since there is no console on this
> + * port at this time, the port->lock is not initialized yet.)
> + */
> static void meson_uart_reset(struct uart_port *port)
> {
> u32 val;
> @@ -267,9 +275,12 @@ static void meson_uart_reset(struct uart_port *port)
>
> static int meson_uart_startup(struct uart_port *port)
> {
> + unsigned long flags;
> u32 val;
> int ret = 0;
>
> + spin_lock_irqsave(&port->lock, flags);
> +
> val = readl(port->membase + AML_UART_CONTROL);
> val |= AML_UART_CLEAR_ERR;
> writel(val, port->membase + AML_UART_CONTROL);
> @@ -285,6 +296,8 @@ static int meson_uart_startup(struct uart_port *port)
> val = (AML_UART_RECV_IRQ(1) | AML_UART_XMIT_IRQ(port->fifosize / 2));
> writel(val, port->membase + AML_UART_MISC);
>
> + spin_unlock_irqrestore(&port->lock, flags);
> +
> ret = request_irq(port->irq, meson_uart_interrupt, 0,
> port->name, port);
>
>
> base-commit: 672c0c5173427e6b3e2a9bbb7be51ceeec78093a
--
js
suse labs
next prev parent reply other threads:[~2022-05-09 5:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-08 10:35 [PATCH v1] serial: meson: acquire port->lock in startup() John Ogness
2022-05-09 5:42 ` Jiri Slaby [this message]
2022-05-09 7:36 ` Neil Armstrong
2022-05-10 9:37 ` Petr Mladek
2022-05-10 9:49 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c0eac83f-8483-7709-b558-561ff7a382b0@kernel.org \
--to=jirislaby@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jbrunet@baylibre.com \
--cc=john.ogness@linutronix.de \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=narmstrong@baylibre.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox