linux-kernel - Re: [PATCH v7 13/19] dmaengine: tegra-apb: Don't stop cyclic DMA in a case of error condition

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]

Message-ID: <ad86f2a4-6fa0-7958-aad7-1b18f02cabfe@gmail.com>
Date:   Tue, 4 Feb 2020 18:55:03 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Vinod Koul <vkoul@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     dmaengine@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 13/19] dmaengine: tegra-apb: Don't stop cyclic DMA in a
 case of error condition

04.02.2020 15:02, Jon Hunter пишет:
> 
> On 02/02/2020 22:28, Dmitry Osipenko wrote:
>> There is no harm in keeping DMA active in the case of error condition,
>> which should never happen in practice anyways. This will become useful
>> for the next patch, which will keep RPM enabled only during of DMA
>> transfer, and thus, it will be much nicer if cyclic DMA handler could
>> not touch the DMA-enable state.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
>> ---
>>  drivers/dma/tegra20-apb-dma.c | 9 +++++----
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
>> index c7dc27ef1856..50abce608318 100644
>> --- a/drivers/dma/tegra20-apb-dma.c
>> +++ b/drivers/dma/tegra20-apb-dma.c
>> @@ -571,9 +571,7 @@ static bool handle_continuous_head_request(struct tegra_dma_channel *tdc,
>>  	 */
>>  	hsgreq = list_first_entry(&tdc->pending_sg_req, typeof(*hsgreq), node);
>>  	if (!hsgreq->configured) {
>> -		tegra_dma_stop(tdc);
>> -		dev_err(tdc2dev(tdc), "Error in DMA transfer, aborting DMA\n");
>> -		tegra_dma_abort_all(tdc);
>> +		dev_err_ratelimited(tdc2dev(tdc), "Error in DMA transfer\n");
> 
> While we are at it, a more descriptive error message could be good here.
> I believe that this condition would indicate a potential underrun condition.

Yes, this error indicates the underrun and indeed the error message
could be improved. I'll change it in v8.

>>  		return false;
>>  	}
>>  
>> @@ -772,7 +770,10 @@ static int tegra_dma_terminate_all(struct dma_chan *dc)
>>  	if (!list_empty(&tdc->pending_sg_req) && was_busy) {
>>  		sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq),
>>  					 node);
>> -		sgreq->dma_desc->bytes_transferred +=
>> +		dma_desc = sgreq->dma_desc;
>> +
>> +		if (dma_desc->dma_status != DMA_ERROR)
>> +			dma_desc->bytes_transferred +=
>>  				get_current_xferred_count(tdc, sgreq, wcount);
> 
> I am wondering if we need to check this here? I assume that the transfer
> count would still reflect the amount of data transferred, even if some
> was dropped. We will never know how much data was lost.

I'm wondering too.. stopping DMA in a error case removes this ambiguity
and that's why in my previous answer to v6 I suggested to drop this patch.

Do you think it's worth to keep this patch?