Multiple iommu domains and iommu groups are getting created for the devices
sharing same SID. It is expected for devices sharing same SID to be in same
iommu group and same iommu domain.
This is leading to context faults when one device is accessing IOVA from
other device which shouldn't be the case for devices sharing same SID.
Fix this by protecting iommu domain and iommu group creation with mutexes.
Ashish Mhetre (1):
iommu: Fix race condition during default domain allocation
Krishna Reddy (1):
iommu/arm-smmu: Fix race condition during iommu_group creation
drivers/iommu/arm/arm-smmu/arm-smmu.c | 6 +++++-
drivers/iommu/iommu.c | 2 ++
2 files changed, 7 insertions(+), 1 deletion(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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, it ends up in creating two domains for two display
devices which should ideally be in same domain.
iommu_alloc_default_domain() checks whether domain is already allocated for
given iommu group, but due to this race the check condition is failing and
two different domains are getting created.
This is leading to context faults when one device is accessing the IOVA
mapped by other device.
Fix this by protecting iommu_alloc_default_domain() call with group->mutex.
With this fix serialization will happen only for the devices sharing same
group. Also, only first device in group will hold the mutex till group is
created and for rest of the devices it will just check for existing domain
and then release the mutex.
Signed-off-by: Ashish Mhetre <redacted>
---
Changes since V1:
- Update the commit message per Will's suggestion
drivers/iommu/iommu.c | 2 ++
1 file changed, 2 insertions(+)
From: Krishna Reddy <vdumpa@nvidia.com>
iommu_group is getting created more than once during asynchronous multiple
display heads(devices) probe on Tegra194 SoC. All the display heads share
same SID and are expected to be in same iommu_group.
As arm_smmu_device_group() is not protecting group creation across devices,
it is leading to multiple groups creation across devices with same SID and
subsequent IOMMU faults.
During race, the iommu_probe_device() call for two display devices is
ending up in arm_smmu_device_group() twice and hence two groups are getting
created. Ideally after group creation for first display device, same group
should be used by second display device.
This race is leading to context faults when one display device is accessing
IOVA from other display device which shouldn't be the case for devices
sharing same SID.
Fix this by protecting group creation with smmu->stream_map_mutex.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
Changes since V1:
- Update the commit message per Will's suggestion
drivers/iommu/arm/arm-smmu/arm-smmu.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Multiple iommu domains and iommu groups are getting created for the devices
sharing same SID. It is expected for devices sharing same SID to be in same
iommu group and same iommu domain.
This is leading to context faults when one device is accessing IOVA from
other device which shouldn't be the case for devices sharing same SID.
Fix this by protecting iommu domain and iommu group creation with mutexes.
Ashish Mhetre (1):
iommu: Fix race condition during default domain allocation
Krishna Reddy (1):
iommu/arm-smmu: Fix race condition during iommu_group creation
drivers/iommu/arm/arm-smmu/arm-smmu.c | 6 +++++-
drivers/iommu/iommu.c | 2 ++
2 files changed, 7 insertions(+), 1 deletion(-)
Hi,
Can you please help in reviewing this V2 change? Please let me know if
anymore changes are required.
Thanks,
Ashish Mhetre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-08-02 15:16:23
On Fri, Jun 18, 2021 at 02:00:35AM +0530, Ashish Mhetre wrote:
Multiple iommu domains and iommu groups are getting created for the devices
sharing same SID. It is expected for devices sharing same SID to be in same
iommu group and same iommu domain.
This is leading to context faults when one device is accessing IOVA from
other device which shouldn't be the case for devices sharing same SID.
Fix this by protecting iommu domain and iommu group creation with mutexes.
Robin -- any chance you could take a look at these, please? You had some
comments on the first version which convinced me that they are needed,
but I couldn't tell whether you wanted to solve this a different way or not.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-08-02 15:46:47
On 2021-08-02 16:16, Will Deacon wrote:
On Fri, Jun 18, 2021 at 02:00:35AM +0530, Ashish Mhetre wrote:
quoted
Multiple iommu domains and iommu groups are getting created for the devices
sharing same SID. It is expected for devices sharing same SID to be in same
iommu group and same iommu domain.
This is leading to context faults when one device is accessing IOVA from
other device which shouldn't be the case for devices sharing same SID.
Fix this by protecting iommu domain and iommu group creation with mutexes.
Robin -- any chance you could take a look at these, please? You had some
comments on the first version which convinced me that they are needed,
but I couldn't tell whether you wanted to solve this a different way or not.
Sorry, I was lamenting that this came to light due to the
of_iommu_configure() flow being yucky, but that wasn't meant to imply
that there aren't - or couldn't be in future - better reasons for
iommu_probe_device() to be robust against concurrency anyway. I do think
these are legitimate fixes to make in their own right, even if the
current need might get swept back under the rug in future.
I would say, however, that the commit messages seem to focus too much on
the wrong details and aren't overly useful, and patch #2 is missing
Ashish's sign-off.
Thanks,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-08-09 14:54:28
On Mon, Aug 02, 2021 at 04:46:37PM +0100, Robin Murphy wrote:
On 2021-08-02 16:16, Will Deacon wrote:
quoted
On Fri, Jun 18, 2021 at 02:00:35AM +0530, Ashish Mhetre wrote:
quoted
Multiple iommu domains and iommu groups are getting created for the devices
sharing same SID. It is expected for devices sharing same SID to be in same
iommu group and same iommu domain.
This is leading to context faults when one device is accessing IOVA from
other device which shouldn't be the case for devices sharing same SID.
Fix this by protecting iommu domain and iommu group creation with mutexes.
Robin -- any chance you could take a look at these, please? You had some
comments on the first version which convinced me that they are needed,
but I couldn't tell whether you wanted to solve this a different way or not.
Sorry, I was lamenting that this came to light due to the
of_iommu_configure() flow being yucky, but that wasn't meant to imply that
there aren't - or couldn't be in future - better reasons for
iommu_probe_device() to be robust against concurrency anyway. I do think
these are legitimate fixes to make in their own right, even if the current
need might get swept back under the rug in future.
I would say, however, that the commit messages seem to focus too much on the
wrong details and aren't overly useful, and patch #2 is missing Ashish's
sign-off.