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=-5.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 ABD99C2B9F4 for ; Thu, 17 Jun 2021 17:50:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6FC49613CB for ; Thu, 17 Jun 2021 17:50:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FC49613CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zwU99UplU0jE6uj2cojp23Vil9RCN26CdbDRylp5btA=; b=MYS5jFJkUQWB3f CU1TzxRBmOtcCuNxaR2APVp9dFt51J4Q0Wq/sXbf0lefSGA3NO4GNI7nLvFuCZufPQkZgwwZfxu88 4rtE+Ek92Xbu6tg+Ym0lDE5IzlVk3YzUfOgD4LhMLpHYIArvbrUCZhOdNMIoBXaxDhYHqAikJWLuO 95hJrj3VJJAb/ccI47GZwioI0Y/3CHOt6JgCeWac+xIvn6jPkIBFDloGXHObVRh8TcK6OcMyt8gAW CPDfU+UlBAaHWbMDo1KYqkkywoijrH7XvlXWuDM5UJNB0LGbTKtlMT5seMju6AE7vlUTv1XOtF7Az saVRkQWmNbWmaRj+BK8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltw8b-00BHMM-JD; Thu, 17 Jun 2021 17:49:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltw8X-00BHLd-E4 for linux-arm-kernel@lists.infradead.org; Thu, 17 Jun 2021 17:49:06 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E782C613CB; Thu, 17 Jun 2021 17:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623952145; bh=PEswRSOUEybmrluFbTBGtoEux41ybWZrhm0/5ADHUig=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SRgVQddYQNsX/0bSReJIMePYroJG5R758EyKUDaj8Yz83/tvT+yuc4bWIU/ujjZkt Wv55bqQNR+hlU1Aa1D7IEWIsDpPiiwYdRd4YifEV78OcGVjqb6ftUvgL1xW4Xst4rE lt2+XMMUhQW9cMW7acVtOTW1j4Yt0ClW/MyxIzGi6FBPEB9mR+UUzq8SVbxABPYO9/ LUxHiW+DrPi1FzOA5zInVb9Mf3e9kDZJ7jlt2Y+w/4VfLWqptN5V/w5pe7W1kNejYa efDZ4y9uRMklWBPAjOsYVNLPhdqc4sDj13XfdBDfn6V+BLJqMZixAQM14wU2KTbha6 /SmYiHn8JO0fA== Date: Thu, 17 Jun 2021 18:49:00 +0100 From: Will Deacon To: Ashish Mhetre Subject: Re: [PATCH 1/2] iommu: Fix race condition during default domain allocation Message-ID: <20210617174859.GD24813@willie-the-truck> References: <1623298614-31755-1-git-send-email-amhetre@nvidia.com> <1623298614-31755-2-git-send-email-amhetre@nvidia.com> <20210611104524.GD15274@willie-the-truck> <315fe1c5-2685-6ee3-2aa4-35a27233127b@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <315fe1c5-2685-6ee3-2aa4-35a27233127b@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210617_104905_549594_D6EB31DF X-CRM114-Status: GOOD ( 24.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Robin Murphy , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 17, 2021 at 11:21:39AM +0530, Ashish Mhetre wrote: > > > On 6/11/2021 6:19 PM, Robin Murphy wrote: > > External email: Use caution opening links or attachments > > > > > > On 2021-06-11 11:45, Will Deacon wrote: > > > On Thu, Jun 10, 2021 at 09:46:53AM +0530, Ashish Mhetre wrote: > > > > Domain is getting created more than once during asynchronous multiple > > > > display heads(devices) probe. All the display heads share same SID and > > > > are expected to be in same domain. As iommu_alloc_default_domain() call > > > > is not protected, the group->default_domain and group->domain are ending > > > > up with different domains and leading to subsequent IOMMU faults. > > > > Fix this by protecting iommu_alloc_default_domain() call with > > > > group->mutex. > > > > > > Can you provide some more information about exactly what the h/w > > > configuration is, and the callstack which exhibits the race, please? > > > > It'll be basically the same as the issue reported long ago with PCI > > groups in the absence of ACS not being constructed correctly. Triggering > > the iommu_probe_device() replay in of_iommu_configure() off the back of > > driver probe is way too late and allows calls to happen in the wrong > > order, or indeed race in parallel as here. Fixing that is still on my > > radar, but will not be simple, and will probably go hand-in-hand with > > phasing out the bus ops (for the multiple-driver-coexistence problem). > > > For iommu group creation, the stack flow during race is like: > Display device 1: > iommu_probe_device -> iommu_group_get_for_dev -> arm_smmu_device_group > Display device 2: > iommu_probe_device -> iommu_group_get_for_dev -> arm_smmu_device_group > > And this way it ends up in creating 2 groups for 2 display devices sharing > same SID. > Ideally for 2nd display device, iommu_group_get call from > iommu_group_get_for_dev should return same group as 1st display device. But > due to the race, it ends up with 2 groups. > > For default domain, the stack flow during race is like: > Display device 1: > iommu_probe_device -> iommu_alloc_default_domain -> arm_smmu_domain_alloc > Display device 2: > iommu_probe_device -> iommu_alloc_default_domain -> arm_smmu_domain_alloc > > Here also 2nd device should already have domain allocated and > 'if(group->default_domain)' condition from iommu_alloc_default_domain should > be true for 2nd device. > > Issue with this is IOVA accesses from 2nd device results in context faults. Thanks for the explanation (also Robin and Krishna). Please put some of this in the commit message for the next version. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel