Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 4.19 024/113] tty: serial: msm_serial: avoid system lockup
 condition
To:     Pavel Machek <pavel@denx.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Sasha Levin <sashal@kernel.org>
References: <20190729190655.455345569@linuxfoundation.org>
 <20190729190701.631193260@linuxfoundation.org> <20190731190533.GA4630@amd>
From:   Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Message-ID: <ca8ee0ab-dac5-28db-cac2-20e188473da6@linaro.org>
Date:   Wed, 31 Jul 2019 22:34:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20190731190533.GA4630@amd>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 7/31/19 21:05, Pavel Machek wrote:
> Hi!

hi Pavel,

> 
>> [ 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?

considering the original unbounded definition, it is hard to determine
what would be a good amount of time to wait (msm_serial can be used for
BT comms and I am not sure how critical that link might be for different
clients..and I didnt want to create a regression hence the half a second
delay).

yeah, I don't think disabling interrupts for half a second is a good
idea on most systems hence why I chose it that big.

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

the half a second timeout didnt mean to be accurate but a worst case
scenario...I am not sure accuracy matters.

> 
>> +++ 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?

I did consider this but then I thought that 1/2 second without
interrupts on the core should not go unnoticed. But I might be wrong.

> 
> Thanks,
> 								Pavel
>