From: Will Deacon <will@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Ashish Mhetre <amhetre@nvidia.com>,
vdumpa@nvidia.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Patch V2 0/2] iommu/arm-smmu: Fix races in iommu domain/group creation
Date: Mon, 9 Aug 2021 15:54:20 +0100 [thread overview]
Message-ID: <20210809145420.GB1458@willie-the-truck> (raw)
In-Reply-To: <9c38c53c-c145-097a-4c7e-40f1c06a1f01@arm.com>
On Mon, Aug 02, 2021 at 04:46:37PM +0100, Robin Murphy wrote:
> On 2021-08-02 16:16, Will Deacon wrote:
> > 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.
>
> 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.
Ashish -- please can you send a v3 fixing these issues?
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Ashish Mhetre <amhetre@nvidia.com>,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [Patch V2 0/2] iommu/arm-smmu: Fix races in iommu domain/group creation
Date: Mon, 9 Aug 2021 15:54:20 +0100 [thread overview]
Message-ID: <20210809145420.GB1458@willie-the-truck> (raw)
In-Reply-To: <9c38c53c-c145-097a-4c7e-40f1c06a1f01@arm.com>
On Mon, Aug 02, 2021 at 04:46:37PM +0100, Robin Murphy wrote:
> On 2021-08-02 16:16, Will Deacon wrote:
> > 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.
>
> 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.
Ashish -- please can you send a v3 fixing these issues?
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Ashish Mhetre <amhetre@nvidia.com>,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [Patch V2 0/2] iommu/arm-smmu: Fix races in iommu domain/group creation
Date: Mon, 9 Aug 2021 15:54:20 +0100 [thread overview]
Message-ID: <20210809145420.GB1458@willie-the-truck> (raw)
In-Reply-To: <9c38c53c-c145-097a-4c7e-40f1c06a1f01@arm.com>
On Mon, Aug 02, 2021 at 04:46:37PM +0100, Robin Murphy wrote:
> On 2021-08-02 16:16, Will Deacon wrote:
> > 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.
>
> 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.
Ashish -- please can you send a v3 fixing these issues?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-08-09 14:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 20:30 [Patch V2 0/2] iommu/arm-smmu: Fix races in iommu domain/group creation Ashish Mhetre
2021-06-17 20:30 ` Ashish Mhetre
2021-06-17 20:30 ` Ashish Mhetre
2021-06-17 20:30 ` [Patch V2 1/2] iommu: Fix race condition during default domain allocation Ashish Mhetre
2021-06-17 20:30 ` Ashish Mhetre
2021-06-17 20:30 ` Ashish Mhetre
2021-06-17 20:30 ` [Patch V2 2/2] iommu/arm-smmu: Fix race condition during iommu_group creation Ashish Mhetre
2021-06-17 20:30 ` Ashish Mhetre
2021-06-17 20:30 ` Ashish Mhetre
2021-07-15 4:44 ` [Patch V2 0/2] iommu/arm-smmu: Fix races in iommu domain/group creation Ashish Mhetre
2021-07-15 4:44 ` Ashish Mhetre
2021-07-15 4:44 ` Ashish Mhetre via iommu
2021-08-02 15:16 ` Will Deacon
2021-08-02 15:16 ` Will Deacon
2021-08-02 15:16 ` Will Deacon
2021-08-02 15:46 ` Robin Murphy
2021-08-02 15:46 ` Robin Murphy
2021-08-02 15:46 ` Robin Murphy
2021-08-09 14:54 ` Will Deacon [this message]
2021-08-09 14:54 ` Will Deacon
2021-08-09 14:54 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210809145420.GB1458@willie-the-truck \
--to=will@kernel.org \
--cc=amhetre@nvidia.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=vdumpa@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.