Received: by 10.223.164.202 with SMTP id h10csp604139wrb; Tue, 14 Nov 2017 06:48:22 -0800 (PST) X-Google-Smtp-Source: AGs4zMZSpq+GKKZff6l6srdiYUj1HkLldXRy+qFmBVrx4CJtkq3Wmi5GktAp9KauDhDnLdWuq0ZN X-Received: by 10.99.109.2 with SMTP id i2mr12556503pgc.269.1510670902149; Tue, 14 Nov 2017 06:48:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510670902; cv=none; d=google.com; s=arc-20160816; b=VeCDV1PjVnwYsCF0vb2f+DpfPCBqdnrIiSGOBwhlyZVmbk+a+M8S1Flm7CpFVFNmKX xrJZW3hDc9Kl7Zno5lt1gYq7NvLIw+nl02wpI/RhlfzHLFL/Fzhyuv0ZnqVFq9dZRXvl swrkZl4B8RSUj6jRHDJSbcT58MwDBfiqf8hTI8T8B4vomi1xhUZz94MteOCrpJuve+Li e03sxnvLw/QRqWI832LqaYwTQa3DZhT3nE0ubkYBzjueY5kHOQY7XpcN29S8B+jyYXjp mqFvUupaytvMwrz2Mo86+XFo+tUxyJIjE4F12aFWE5SLvTFzS58yHrijNB0hzob4jn8q tSpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature:arc-authentication-results; bh=GW00cXKzR7xZfy5g3jQoVoHGnyhfYd77/LyjSsCnXc8=; b=DpSu1CHCEhaPJyFnQiWV6jveXxEXef58wiVYfdnGNKfK4airfBsrFM1VH6OnbOTm1u XFyxLRJi3PohTE8qLXWUuIS/y4Ey9zbAZ1rLMhsmFgXLU7vUCu8TwQqf/W2wU6B4G77K gYKUQzqFbiKtOuM4d3kvs9T3w6OCh7o5MGCPv6FBzno7Zd+/g6OQRryawchnokvBZCXP OQ8o3ntXrMh6mX/Yi5Y6l05PS0TeUkTU/uNuA3JhXMPI4vq5vPYwUhiZKEpyWvZWbnLI 65biAAZvtLlxZ1YuToZrnBGjtm+UJcEeo0iZ/Cdo6GM9v/SoREhGYZgVxxLW7co2WpRE 3K3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=UFL+PU7g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l12si16087086pgn.609.2017.11.14.06.48.09; Tue, 14 Nov 2017 06:48:22 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=UFL+PU7g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754630AbdKNOrZ (ORCPT + 87 others); Tue, 14 Nov 2017 09:47:25 -0500 Received: from lelnx194.ext.ti.com ([198.47.27.80]:18575 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752360AbdKNOrR (ORCPT ); Tue, 14 Nov 2017 09:47:17 -0500 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id vAEEkUJU032442; Tue, 14 Nov 2017 08:46:30 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1510670790; bh=KX+RhhzobWNzDNePOCsnSuVg6D7U1DDaq9Vp2ZesjHY=; h=Subject:To:References:CC:From:Date:In-Reply-To; b=UFL+PU7g8XNxLPFGOxw71testmqpGthG+aC3KEjq9+jyDNcIr+itTB+SVqK+8DlaS NKh73TheiPzT4YBk3/WI0Sp9qlDFx1YDcRBq4u5Xed/U/V4z/YFeElo1/0oN2LNo1J ZazQW5I1tRmBA1Nqs8+fU/9X8vK4BR9f2qZsiYKs= Received: from DLEE101.ent.ti.com (dlee101.ent.ti.com [157.170.170.31]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id vAEEkU34007605; Tue, 14 Nov 2017 08:46:30 -0600 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 14 Nov 2017 08:46:30 -0600 Received: from dflp32.itg.ti.com (10.64.6.15) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend Transport; Tue, 14 Nov 2017 08:46:30 -0600 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id vAEEkSCH009247; Tue, 14 Nov 2017 08:46:28 -0600 Subject: Re: [PATCH 00/10] dmaengine: fix race with vchan_complete To: , Russell King References: <20171114143212.8311-1-peter.ujfalusi@ti.com> CC: , , , From: Peter Ujfalusi Message-ID: Date: Tue, 14 Nov 2017 16:47:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171114143212.8311-1-peter.ujfalusi@ti.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Russell, I have missed you from the To: list of this series by mistake, I'm sorry about that. - P�ter On 2017-11-14 16:32, Peter Ujfalusi wrote: > Hi, > > With the introduction of .device_synchronize callback it was thought that the > race caused crash observed in vchan_complete is fixed, but unfortunately it can > still happen. > > The observed scenario (really hard to reproduce) is: > Cyclic mode > - DMA period interrupt > - call to vchan_cyclic_callback() which sets vc->cyclic to vd and schedules the > vchan_complete tasklet > - .terminate_all is called > - we make sure that no further DMA irqs are going to be handled, but the > tasklet had been already scheduled > - we free up the descriptor to avoid leaking memory > - the vchan_complete tasklet starts to execute and it checks vc->cyclic, which > is not NULL, saves the vd pointer (which points to an already freed up memory) > and try to access it later to call the callback > - the tasklet_kill() in .device_synchronize will make sure that the tasklet is > going to finish it's execution if it is already scheduled, it can only help if > the tasklet is yet to be executed. > > At this point it is just matter of luck if the vc->cyclic is still pointing to > an unchanged memory location or it is taken into use and thus it is corrupted. > > My first approach was to just set vc->cyclic to NULL in the .terminate_all > callback, but that still have theoritical race: if the vchan_complete is > executing and it saves the vd from vc->cyclic (protected by the vc->lock). If at > that point the .terminate_all is called it will wait for the lock and start > executing. _if_ the .terminate_all free up the vd before the vchan_complete > reaches the point when it is going to call the callback, then we have the race. > > The series will do this: > - the drivers should call vchan_terminate_vdesc() instead of directly freeing up > the descriptor. vchan_terminate_vdesc() will save the vd as vc->vd_terminated > and will set the vc->cyclic to NULL, all while holding the lock. > - the drivers must implement the .device_synchronize callback and within the > vchan_synchronize() we free up the vc->vd_terminated after we killed the > tasklet. > > I have tested this on platforms using TI's eDMA and sDMA and have not seen any > side effect so far and a client tested similar set on a setup where it was easy > to reproduce the race. > > By looking for similar patterns in other drivers I have implemented the fix for > the ones where it looked straight forward. > > Regards, > Peter > --- > Peter Ujfalusi (10): > dmaengine: virt-dma: Add helper to free/reuse a descriptor > dmaengine: virt-dma: Support for race free transfer termination > dmaengine: omap-dma: Use vchan_terminate_vdesc() instead of desc_free > dmaengine: edma: Use vchan_terminate_vdesc() instead of desc_free > dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of > desc_free > dmaengine: dma-jz4780: Use vchan_terminate_vdesc() instead of > desc_free > dmaengine: amba-pl08x: Use vchan_terminate_vdesc() instead of > desc_free > dmaengine: img-mdc-dma: Use vchan_terminate_vdesc() instead of > desc_free > dmaengine: k3dma: Use vchan_terminate_vdesc() instead of desc_free > dmaengine: s3c24xx-dma: Use vchan_terminate_vdesc() instead of > desc_free > > drivers/dma/amba-pl08x.c | 11 ++++++++++- > drivers/dma/bcm2835-dma.c | 10 +++++++++- > drivers/dma/dma-jz4780.c | 10 +++++++++- > drivers/dma/edma.c | 7 ++----- > drivers/dma/img-mdc-dma.c | 17 ++++++++++++----- > drivers/dma/k3dma.c | 10 +++++++++- > drivers/dma/omap-dma.c | 2 +- > drivers/dma/s3c24xx-dma.c | 11 ++++++++++- > drivers/dma/virt-dma.c | 5 +---- > drivers/dma/virt-dma.h | 44 ++++++++++++++++++++++++++++++++++++++++++++ > 10 files changed, 107 insertions(+), 20 deletions(-) > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From 1584052452603055509@xxx Tue Nov 14 14:35:39 +0000 2017 X-GM-THRID: 1584052452603055509 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread