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=-9.4 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 08DE3C433E1 for ; Thu, 20 Aug 2020 18:23:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CA8C0207DE for ; Thu, 20 Aug 2020 18:23:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=metafoo.de header.i=@metafoo.de header.b="mccu0oQk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727113AbgHTSXv (ORCPT ); Thu, 20 Aug 2020 14:23:51 -0400 Received: from www381.your-server.de ([78.46.137.84]:54198 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726949AbgHTSXu (ORCPT ); Thu, 20 Aug 2020 14:23:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metafoo.de; s=default2002; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=Pba3wqITnv1HSpWANOUiwdXFXFAyf2fUBM6+eV5vKqA=; b=mccu0oQkjLx5k/gEQ8IzLxYpyX h1dzqZiLk5lGWwrDefLML+xi1PbKVHeCS5wmwalrBkanPFJ7s1LLy2WCXjw0HGngC+k9wNOUTVUL7 hCRZ1nnCa5inJZ0drhD9yckBGW5WtMjfHzT6XyFp/xb4iYmrQlPqjuqdKZZi0jfk7EgyQOLFRvwoL 1H/Ll+strO7/vg3Shygo90l1iafT5nuCFZZeutaheRVbZjn+iAuB+/GI3iKCy/WbwUy3+nQ41gR/H DnLeKokhdtC+5e2nFtVBDJxz65+gTJdJaic0DqE3a4rAL1zNWjV4nHkKN/IHcShx7TFk+sJH9C47x ZbXCd42A==; Received: from sslproxy06.your-server.de ([78.46.172.3]) by www381.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1k8pDt-0005Xe-3p; Thu, 20 Aug 2020 20:23:37 +0200 Received: from [2001:a61:25dc:8101:9e5c:8eff:fe01:8578] by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8pDs-000D44-US; Thu, 20 Aug 2020 20:23:36 +0200 Subject: Re: [PATCH] drivers/dma/dma-jz4780: Fix race condition between probe and irq handler To: Paul Cercueil , madhuparnabhowmik10@gmail.com Cc: dan.j.williams@intel.com, vkoul@kernel.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, andrianov@ispras.ru, ldv-project@linuxtesting.org References: <20200816072253.13817-1-madhuparnabhowmik10@gmail.com> From: Lars-Peter Clausen Message-ID: Date: Thu, 20 Aug 2020 20:23:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.102.4/25905/Thu Aug 20 15:09:58 2020) Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 8/20/20 1:59 PM, Paul Cercueil wrote: > Hi, > > Le dim. 16 août 2020 à 12:52, madhuparnabhowmik10@gmail.com a écrit : >> From: Madhuparna Bhowmik >> >> In probe IRQ is requested before zchan->id is initialized which can be >> read in the irq handler. Hence, shift request irq and enable clock after >> other initializations complete. Here, enable clock part is not part of >> the race, it is just shifted down after request_irq to keep the error >> path same as before. >> >> Found by Linux Driver Verification project (linuxtesting.org). >> >> Signed-off-by: Madhuparna Bhowmik > > I don't think there is a race at all, the interrupt handler won't be > called before the DMA is registered. > From a purely formal verification perspective there is a bug. The interrupt could fire if i.e. the hardware is buggy or something. In general it is a good idea to not request the IRQ until all the resources that are used in the interrupt handler are properly set up. Even if you know that in practice the interrupt will never fire this early.