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:   Wed, 31 Jul 2019 21:05:34 +0200
From:   Pavel Machek <pavel@...x.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 024/113] tty: serial: msm_serial: avoid system
 lockup condition

Hi!

> [ Upstream commit ba3684f99f1b25d2a30b6956d02d339d7acb9799 ]
> 
> The function msm_wait_for_xmitr can be taken with interrupts
> disabled. In order to avoid a potential system lockup - demonstrated
> under stress testing conditions on SoC QCS404/5 - make sure we wait
> for a bounded amount of time.
> 
> Tested on SoC QCS404.

How long did it take to timeout?

Because... this is supposed to loop for 0.5 second with interrupts
disabled, but 500000*udelay(1) is probably going to wait for more than
that.

Is 500msec reasonable with interrupts disabled?

Should it use something like 5000*udelay(100), instead, as that has
chance to result in closer-to-500msec wait?

> +++ b/drivers/tty/serial/msm_serial.c
> @@ -383,10 +383,14 @@ static void msm_request_rx_dma(struct msm_port *msm_port, resource_size_t base)
>  
>  static inline void msm_wait_for_xmitr(struct uart_port *port)
>  {
> +	unsigned int timeout = 500000;
> +
>  	while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
>  		if (msm_read(port, UART_ISR) & UART_ISR_TX_READY)
>  			break;
>  		udelay(1);
> +		if (!timeout--)
> +			break;
>  	}
>  	msm_write(port, UART_CR_CMD_RESET_TX_READY, UART_CR);
>  }

Plus, should it do some kind of dev_err() to let users know that
something went very wrong with their serial?

Thanks,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ