serial: tegra: Handle another RX race condition
Commit 853a6997 ("serial: tegra: handle race condition on uart rx side") attempted to fix a race condition between the RX end of transmission interrupt and RX DMA completion callback. Despite this fix there is still another case where these two paths can race and result in duplicated data. The race condition is as follows: 1. DMA completion interrupt occurs and schedules tasklet to call DMA callback. 2. DMA callback for the UART driver starts to execute. This will copy the data from the DMA buffer and restart the DMA. This is done under uart port spinlock. 3. During the callback, UART interrupt is raised for end of receive. The UART ISR runs and waits to acquire port spinlock held by the DMA callback. 4. DMA callback gives up spinlock after copying the data, but before restarting DMA. 5. UART ISR acquires the spin lock and reads the same DMA buffer because DMA has not been restarted yet. The release of the spinlock during the DMA callback was introduced by commit 9b88748b ("tty: serial: tegra: drop uart_port->lock before calling tty_flip_buffer_push()") to fix a spinlock lock-up issue when calling tty_flip_buffer_push(). However, since then commit a9c3f68f ("tty: Fix low_latency BUG") migrated tty_flip_buffer_push() to always use a workqueue, allowing tty_flip_buffer_push() to be called from within atomic sections. Therefore, we can remove the unlocking of the spinlock from the DMA callback and UART ISR and this will ensure that the race condition no longer occurs. Reported-by: Christopher Freeman <cfreeman@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment