From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5000CC432C3 for ; Mon, 18 Nov 2019 11:47:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 239CE2084D for ; Mon, 18 Nov 2019 11:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574077666; bh=Dg8TgUaybW9Lk1cMVQagTqCFOISsTWLZ3Y0G80dT4aA=; h=Subject:To:From:Date:List-ID:From; b=p9AcNq/2nASPNTC3S7rdm4DWiivI+rdO3s8ZDqrg/SAZXmzHRu/ni6OD0GQ4fzKQt PfqjvGLzOhI2io84n//uwgW8kchhUXLpvbUSVDfAR9ufTb9S3CEjauUFL1ofhk1e6D TOcwbLid6+MUbgAclgcmocrMnyjkZ5T4NnuVCkRk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726461AbfKRLrp (ORCPT ); Mon, 18 Nov 2019 06:47:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:55246 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbfKRLrp (ORCPT ); Mon, 18 Nov 2019 06:47:45 -0500 Received: from localhost (unknown [89.205.134.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 27AF720748; Mon, 18 Nov 2019 11:47:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574077664; bh=Dg8TgUaybW9Lk1cMVQagTqCFOISsTWLZ3Y0G80dT4aA=; h=Subject:To:From:Date:From; b=tjMLt64rT9ARVQqv0S8pReCA36J47ZHOXy1N1d684hvYjWEsMCquX/eM+cocr843y S45Sne5mRIY9rLe0oJbzqdmUKUUfT7kLHK0CX458oqwN50j43TyI2GAL/CmslIj9CH FT7Rpu1ZeMGLn7F54Oj2wuoGH+uJHLmkQrq//Gf0= Subject: patch "serial: pl011: Fix DMA ->flush_buffer()" added to tty-testing To: vincent.whitchurch@axis.com, gregkh@linuxfoundation.org, stable@vger.kernel.org From: Date: Mon, 18 Nov 2019 12:47:41 +0100 Message-ID: <157407766113025@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org This is a note to let you know that I've just added the patch titled serial: pl011: Fix DMA ->flush_buffer() to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From f6a196477184b99a31d16366a8e826558aa11f6d Mon Sep 17 00:00:00 2001 From: Vincent Whitchurch Date: Mon, 18 Nov 2019 10:25:47 +0100 Subject: serial: pl011: Fix DMA ->flush_buffer() PL011's ->flush_buffer() implementation releases and reacquires the port lock. Due to a race condition here, data can end up being added to the circular buffer but neither being discarded nor being sent out. This leads to, for example, tcdrain(2) waiting indefinitely. Process A Process B uart_flush_buffer() - acquire lock - circ_clear - pl011_flush_buffer() -- release lock -- dmaengine_terminate_all() uart_write() - acquire lock - add chars to circ buffer - start_tx() -- start DMA - release lock -- acquire lock -- turn off DMA -- release lock // Data in circ buffer but DMA is off According to the comment in the code, the releasing of the lock around dmaengine_terminate_all() is to avoid a deadlock with the DMA engine callback. However, since the time this code was written, the DMA engine API documentation seems to have been clarified to say that dmaengine_terminate_all() (in the identically implemented but differently named dmaengine_terminate_async() variant) does not wait for any running complete callback to be completed and can even be called from a complete callback. So there is no possibility of deadlock if the DMA engine driver implements this API correctly. So we should be able to just remove this release and reacquire of the lock to prevent the aforementioned race condition. Signed-off-by: Vincent Whitchurch Cc: stable Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.com Signed-off-by: Greg Kroah-Hartman --- drivers/tty/serial/amba-pl011.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index 38e2d25f7e23..4b28134d596a 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -813,10 +813,8 @@ __acquires(&uap->port.lock) if (!uap->using_tx_dma) return; - /* Avoid deadlock with the DMA engine callback */ - spin_unlock(&uap->port.lock); - dmaengine_terminate_all(uap->dmatx.chan); - spin_lock(&uap->port.lock); + dmaengine_terminate_async(uap->dmatx.chan); + if (uap->dmatx.queued) { dma_unmap_sg(uap->dmatx.chan->device->dev, &uap->dmatx.sg, 1, DMA_TO_DEVICE); -- 2.24.0