From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V3 0/8] IOMMU probe deferral support
Date: Mon, 7 Nov 2016 19:13:12 +0000 [thread overview]
Message-ID: <20161107191312.GK20591@arm.com> (raw)
In-Reply-To: <006f01d236ae$61751c40$245f54c0$@codeaurora.org>
On Fri, Nov 04, 2016 at 08:46:06PM +0530, Sricharan wrote:
> >>>Yikes, on second look, that definitely shouldn't be happening.
> >>>Everything below is probably the resulting fallout.
> >>
> >>[ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
> >>
> >>I think the above print which says "failed to setup iommu_ops"
> >>because the call ops->add_device failed in of_pci_iommu_configure
> >>is the reason for the failure, in my case i simply do not get this even with
> >>your scripts. ops->add_device succeeds in the rebind as well. So still
> >>checking what could be happening in your case.
> >
> >I was looking at your code base from [1].The ops->add_device
> >callback from of_pci_iommu_configure on the rebind is the
> >one which is causing the failure. But not able to spot out
> >from code which point is causing the failure. It would be very helpful
> >if i can know which is the return value from the add_device callback
> >or point inside add_device callback which fails in your setup.
> >
> >
> >[1] git://linux-arm.org/linux-rm iommu/misc
So this also applies to mainline.
> With little more try, i saw an issue where i had an failure
> similar to what you reported. The issue happens when multiple
> devices fall in to same group due to matching sids. I ended up
> doing a fix like below and it would be nice to verify if it is the same
> that we are seeing in your setup and if the fix makes a difference ?
>
> From: Sricharan R <sricharan@codeaurora•org>
> Date: Fri, 4 Nov 2016 20:28:49 +0530
> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>
> iommu_group_get_for_dev which gets called in the add_device
> callback, increases the reference count of the iommu_group,
> so we do an iommu_group_put after that. iommu_group_get_for_dev
> inturn calls device_group callback and in the case of arm-smmu
> we call generic_device_group/pci_device_group which takes
> care of increasing the group's reference. But when we return
> an already existing group(when multiple devices have same group)
> the reference is not incremented, resulting in issues when the
> remove_device callback for the devices is invoked.
> Fixing the same here.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora•org>
> ---
> drivers/iommu/arm-smmu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 71ce4b6..a1d0b3c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
> group = smmu->s2crs[idx].group;
> }
>
> - if (group)
> + if (group) {
> + iommu_group_get_by_id(iommu_group_id(group));
> return group;
> + }
This is foul :(
I think we should either add a function for incrementing the refcount on a
group, or we should get a handle on the existing aliasing device and get
the group from that. As written, this patch is far too subtle.
Joerg -- do you have any preference?
Will
next prev parent reply other threads:[~2016-11-07 19:13 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20161004170414eucas1p141bebe16e1bf241862833e7ad0270c72@eucas1p1.samsung.com>
2016-10-04 17:03 ` [PATCH V3 0/8] IOMMU probe deferral support Sricharan R
2016-10-04 17:03 ` [PATCH V3 1/8] arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops() Sricharan R
2016-10-04 17:03 ` [PATCH V3 2/8] of: dma: Move range size workaround to of_dma_get_range() Sricharan R
2016-10-04 17:03 ` [PATCH V3 3/8] of: dma: Make of_dma_deconfigure() public Sricharan R
2016-10-04 17:03 ` [PATCH V3 4/8] drivers: platform: Configure dma operations at probe time Sricharan R
2016-10-26 14:07 ` Robin Murphy
2016-10-26 15:04 ` Sricharan
2016-10-27 10:49 ` Lorenzo Pieralisi
2016-11-02 7:05 ` Sricharan
2016-10-04 17:03 ` [PATCH V3 5/8] iommu: of: Handle IOMMU lookup failure with deferred probing or error Sricharan R
2016-10-26 14:52 ` Robin Murphy
2016-10-27 2:55 ` Sricharan
2016-10-04 17:03 ` [PATCH V3 6/8] arm: dma-mapping: Reset the device's dma_ops Sricharan R
2016-10-26 15:07 ` Robin Murphy
2016-10-27 3:37 ` Sricharan
2017-05-23 16:25 ` Russell King - ARM Linux
2017-05-23 16:55 ` Robin Murphy
2017-05-23 17:53 ` Russell King - ARM Linux
2017-05-23 21:46 ` Laurent Pinchart
2017-05-23 22:42 ` Russell King - ARM Linux
2017-05-24 10:31 ` Sricharan R
2017-05-24 11:26 ` Laurent Pinchart
2017-05-24 11:38 ` Sricharan R
2017-05-25 15:05 ` Russell King - ARM Linux
2017-05-26 5:18 ` Sricharan R
2017-05-26 14:04 ` Laurent Pinchart
2016-10-04 17:03 ` [PATCH V3 7/8] arm/arm64: dma-mapping: Call iommu's remove_device callback during device detach Sricharan R
2016-10-26 15:16 ` Robin Murphy
2016-10-27 5:16 ` Sricharan
2016-10-04 17:03 ` [PATCH V3 8/8] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops Sricharan R
2016-10-07 15:40 ` Sricharan
2016-10-26 15:34 ` Robin Murphy
2016-10-27 5:19 ` Sricharan
2016-10-10 12:36 ` [PATCH V3 0/8] IOMMU probe deferral support Marek Szyprowski
2016-10-12 6:24 ` Sricharan
2016-10-24 6:34 ` Marek Szyprowski
2016-10-24 12:30 ` Sricharan
2016-10-17 6:58 ` Sricharan
2016-10-17 7:02 ` Sricharan
2016-10-25 6:25 ` Archit Taneja
2016-10-25 14:35 ` Robin Murphy
2016-10-26 14:44 ` Sricharan
2016-10-26 17:14 ` Robin Murphy
2016-10-27 8:37 ` Sricharan
2016-11-03 22:25 ` Sricharan
2016-11-04 15:16 ` Sricharan
2016-11-07 19:13 ` Will Deacon [this message]
2016-11-07 19:22 ` Robin Murphy
2016-11-09 6:24 ` Sricharan
2016-11-09 16:59 ` Will Deacon
2016-11-14 3:41 ` Sricharan
2016-11-20 15:11 ` Sricharan
2016-11-23 19:54 ` Robin Murphy
2016-11-24 16:10 ` Sricharan
2016-11-24 19:11 ` Robin Murphy
2016-11-28 17:42 ` Sricharan
2016-11-28 18:13 ` Lorenzo Pieralisi
2016-11-30 0:34 ` Sricharan
2016-11-30 12:07 ` Lorenzo Pieralisi
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=20161107191312.GK20591@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox