linux-kernel - Re: [PATCH] tty/serial: Cancel work queue before closing uart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Aug 2023 11:23:14 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Wenhua Lin <Wenhua.Lin@...soc.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        wenhua lin <wenhua.lin1994@...il.com>,
        Xiongpeng Wu <xiongpeng.wu@...soc.com>,
        Zhirong Qiu <zhirong.qiu@...soc.com>,
        Zhaochen Su <Zhaochen.Su@...soc.com>
Subject: Re: [PATCH] tty/serial: Cancel work queue before closing uart

On Fri, 18 Aug 2023, Wenhua Lin wrote:

I've problems following your description below due to grammar errors.

> When the system constantly sleeps and wankes up, plugging and unplugging

wakes

> the USB will probalility trigger a kernel crash problem.

probalility is typoed and I cannot guess which of the words you meant, 
please fix.

If there's a known crash you're fixing here, please quote the crash 
message in the changelog (and you should probably add Fixes: tag too in 
that case).

> The reason is
> that at this time, the system entered deep and turned off uart, and the

"entered deep" lacks probably some word?

> abnormal behavior of plugging and upplugging the USB triggered the read

unplugging.

Why call that abnormal behavior? Isn't USB expected to removed.

> data process of uart, causing access to uart to hang.

Are you saying a read was triggered while the UART was suspended or what?

> The final solution
> we came up with is to cancel the work queue before shutting down uart
> , while ensuring that there is no uart business.

", while ensuring" -> to ensure

"uart business" is too vague, you should replace it with something more 
concrete.

Thanks.

--
 i.

> 
> Signed-off-by: Wenhua Lin <Wenhua.Lin@...soc.com>
> ---
>  drivers/tty/serial/sprd_serial.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
> index b58f51296ace..eddff4360155 100644
> --- a/drivers/tty/serial/sprd_serial.c
> +++ b/drivers/tty/serial/sprd_serial.c
> @@ -20,6 +20,7 @@
>  #include <linux/slab.h>
>  #include <linux/tty.h>
>  #include <linux/tty_flip.h>
> +#include "../tty.h"
>  
>  /* device name */
>  #define UART_NR_MAX		8
> @@ -1221,7 +1222,10 @@ static int sprd_probe(struct platform_device *pdev)
>  static int sprd_suspend(struct device *dev)
>  {
>  	struct sprd_uart_port *sup = dev_get_drvdata(dev);
> +	struct uart_port *uport = &sup->port;
> +	struct tty_port *tty = &uport->state->port;
>  
> +	tty_buffer_cancel_work(tty);
>  	uart_suspend_port(&sprd_uart_driver, &sup->port);
>  
>  	return 0;
>