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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id BF420C48BEB for ; Fri, 16 Feb 2024 12:05:36 +0000 (UTC) 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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=UK1Zz+P5QsZkkmIX1GcUNGLQ5v2fwhD6kSPmP6AVrLU=; b=0FKh71Vluq1sai qhpL+nm9NFolLwMrp2oVgePVJXVm5hILt6udqRcC+6nXk/gB/xDdFD5miOsibspTu20Xfy9/DzzLN yw22bqjW6fmJEErZlOn9U7P4fBQyTBioqAodqhRmOniPpwJ/lZDn+EvQmdwt0pgrC/SUx9RfvyRqu 2fGnA1lpXMD8L7Cxy7IXzjDGx5y4kPP2qLEDc36i+dmRtjAZ2ubJkYhovKsz3FmNJWh5nIiRUp7hG mSRO3xvNcbjD7UP5hkHHSFC9N+SbPuiffT9JKEiiWHlyXFhxDxsDQ+e8BX0ot3OPC21LIXqLrM5vq dnhrswHd6LJrUnEN1oKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rawy2-00000002FBV-172q; Fri, 16 Feb 2024 12:05:22 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rawxz-00000002FAj-3YK5 for linux-arm-kernel@lists.infradead.org; Fri, 16 Feb 2024 12:05:21 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6183F61F5E; Fri, 16 Feb 2024 12:05:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46A1BC43390; Fri, 16 Feb 2024 12:05:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708085118; bh=vL+vbsgg8KG4BovEieOdK28c94kfdv3eTijdDi7zRok=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I6BjzzkSKHxvcdWqcbhND47HDiTU2fwjccLM/3fApUpzOqZOcARDo1JfFMPhflmnB ETEF2QCsq8G1gTlGgSJQgKWAfzSkcC/v4Ahg87aFuqOdKfmaXmv2zVTIVd9Wl7YY8T 7Md2wi+Jc+eQIJbUSoDu6K4tu1t8G2sfuIc06QMZn9HtsOb2LPYIXDPKyQbisNPqcd L3WQJISPK6/1mGNd8b6FMHATRJBJQsWxipG4wCCINH5SHknqUHMB4EQGyGlV9Ix/u1 eiEBGDQRzDcnB4XXfTyIBtPpvw4b9BN7QrAH6HLsCwjQLxqOx5aF7cPWsTpya3tWYF 12feHrdbkvUiA== Date: Fri, 16 Feb 2024 12:05:12 +0000 From: Will Deacon To: Jason Gunthorpe Cc: iommu@lists.linux.dev, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Robin Murphy , Dan Carpenter , Michael Shavit , Nicolin Chen , patches@lists.linux.dev Subject: Re: [PATCH rc v2] iommu/arm-smmu-v3: Do not use GFP_KERNEL under as spinlock Message-ID: <20240216120512.GA1841@willie-the-truck> References: <0-v2-7988c2682634+261-smmu_cd_atomic_jgg@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0-v2-7988c2682634+261-smmu_cd_atomic_jgg@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-20240216_040519_954491_4A73AD04 X-CRM114-Status: GOOD ( 22.18 ) 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: , 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, Feb 15, 2024 at 10:56:57AM -0400, Jason Gunthorpe wrote: > If the SMMU is configured to use a two level CD table then > arm_smmu_write_ctx_desc() allocates a CD table leaf internally using > GFP_KERNEL. Due to recent changes this is being done under a spinlock to > iterate over the device list - thus it will trigger a sleeping while > atomic warning: > > arm_smmu_sva_set_dev_pasid() > mutex_lock(&sva_lock); > __arm_smmu_sva_bind() > arm_smmu_mmu_notifier_get() > spin_lock_irqsave() > arm_smmu_write_ctx_desc() > arm_smmu_get_cd_ptr() > arm_smmu_alloc_cd_leaf_table() > dmam_alloc_coherent(GFP_KERNEL) > > This is a 64K high order allocation and really should not be done > atomically. > > At the moment the rework of the SVA to follow the new API is half > finished. Recently the CD table memory was moved from the domain to the > master, however we have the confusing situation where the SVA code is > wrongly using the RID domains device's list to track which CD tables the > SVA is installed in. > > Remove the logic to replicate the CD across all the domain's masters > during attach. We know which master and which CD table the PASID should be > installed in. > > At the moment SVA is only invoked when dma-iommu.c is in control of the > RID translation, which means we have a single iommu_domain shared across > the entire group and that iommu_domain is not shared outside the group. > > For PCI cases the core code also insists on singleton groups so there is > only ever one entry in the smmu_domain->domains list that is equal to the > master being passed in to arm_smmu_sva_set_dev_pasid(). > > Only non-PCI cases may have multi-device groups. However, the core code it > self will replicate the calls to arm_smmu_sva_set_dev_pasid() across the > entire group so we will still correctly install the CD into each group > members master. Are you sure about this paragraph? arm_smmu_mmu_notifier_get() will return early if it finds an existing notifier in the 'mmu_notifiers' list for the domain, so I don't think we'll actually get as far as installing the CD, will we? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel