linux-kernel - Re: [PATCH] tty: serial: msm: Disable restoring Rx interrupts for DMA Mode

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, 11 May 2016 18:41:26 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Abhishek Sahu <absahu@...eaurora.org>
Cc:	agross@...eaurora.org, david.brown@...aro.org,
	andy.gross@...aro.org, gregkh@...uxfoundation.org, jslaby@...e.com,
	linux-soc@...r.kernel.org, linux-serial@...r.kernel.org,
	sricharan@...eaurora.org, architt@...eaurora.org,
	linux-arm-msm@...r.kernel.org, ntelkar@...eaurora.org,
	galak@...eaurora.org, linux-kernel@...r.kernel.org,
	dmaengine@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Charanya <charanya@...eaurora.org>
Subject: Re: [PATCH] tty: serial: msm: Disable restoring Rx interrupts for
 DMA Mode

On 05/10, Abhishek Sahu wrote:
> From: Charanya <charanya@...eaurora.org>

Was it intentional to only have one name here?

> 
> The Data loss was happening with current QCOM MSM serial driver during
> large file transfer due to simultaneous enabling of both UART and
> DMA interrupt. When UART operates in DMA mode, RXLEV (Rx FIFO over
> watermark) or RXSTALE (stale interrupts) should not be enabled,
> since these conditions will be handled by DMA controller itself.
> If these interrupts are enabled then normal UART ISR will read some
> bytes of data from Rx Buffer and DMA controller will not receive
> these bytes of data, which will cause data loss.
> 
> Now this patch removed the code for enabling of RXLEV and RXSTALE
> interrupt in DMA Rx completion routine.

I'm lost, we keep both these irqs masked (well only if uartdm
version is 1.4 or greater) pretty much the entire time we're
using DMA for RX. msm_start_rx_dma() will mask them and then when
the callback completes we'll unmask them (the part that's deleted
in this patch), but then we'll go back and remask them almost
immediately because we call msm_start_rx_dma() from the dma
completion handler.

Can you clearly describe how this is actually fixing any
problems? What's the sequence of events that happens to cause
corruption?

This does raise the question though why we ever mask/unmask these
interrupts if we're always going to keep them masked while doing
DMA RX. Presumably if we can use DMA to RX, we can always use it
and set things up properly at startup time instead of later on.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project