]> git.itanic.dy.fi Git - linux-stable/commit
iommu/arm-smmu-v3: Hold arm_smmu_asid_lock during all of attach_dev
authorJason Gunthorpe <jgg@nvidia.com>
Mon, 26 Feb 2024 17:07:16 +0000 (13:07 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 13 Apr 2024 11:10:01 +0000 (13:10 +0200)
commit916f0958eacf3a260f6e61b8e8cf9ce2a30c93ee
tree4b303aba7c714d82c4cfddf007baf7ef4b2c3f6f
parentae5876b3b7b2243d874e2afa099e7926122087a1
iommu/arm-smmu-v3: Hold arm_smmu_asid_lock during all of attach_dev

[ Upstream commit 9f7c68911579bc15c57d227d021ccd253da2b635 ]

The BTM support wants to be able to change the ASID of any smmu_domain.
When it goes to do this it holds the arm_smmu_asid_lock and iterates over
the target domain's devices list.

During attach of a S1 domain we must ensure that the devices list and
CD are in sync, otherwise we could miss CD updates or a parallel CD update
could push an out of date CD.

This is pretty complicated, and almost works today because
arm_smmu_detach_dev() removes the master from the linked list before
working on the CD entries, preventing parallel update of the CD.

However, it does have an issue where the CD can remain programed while the
domain appears to be unattached. arm_smmu_share_asid() will then not clear
any CD entriess and install its own CD entry with the same ASID
concurrently. This creates a small race window where the IOMMU can see two
ASIDs pointing to different translations.

       CPU0                                   CPU1
arm_smmu_attach_dev()
   arm_smmu_detach_dev()
     spin_lock_irqsave(&smmu_domain->devices_lock, flags);
     list_del(&master->domain_head);
     spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);

      arm_smmu_mmu_notifier_get()
       arm_smmu_alloc_shared_cd()
arm_smmu_share_asid():
                                          // Does nothing due to list_del above
  arm_smmu_update_ctx_desc_devices()
  arm_smmu_tlb_inv_asid()
       arm_smmu_write_ctx_desc()
 ** Now the ASID is in two CDs
    with different translation

     arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);

Solve this by wrapping most of the attach flow in the
arm_smmu_asid_lock. This locks more than strictly needed to prepare for
the next patch which will reorganize the order of the linked list, STE and
CD changes.

Move arm_smmu_detach_dev() till after we have initialized the domain so
the lock can be held for less time.

Reviewed-by: Michael Shavit <mshavit@google.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Moritz Fischer <moritzf@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/5-v6-96275f25c39d+2d4-smmuv3_newapi_p1_jgg@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c