From: Saravana Kannan via iommu <iommu@lists.linux-foundation.org>
To: John Garry <john.garry@huawei.com>
Cc: iommu@lists.linuxfoundation.org,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Will Deacon <will@kernel.org>,
"Isaac J. Manjarres" <isaacm@codeaurora.org>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v3 09/14] iommu/arm-smmu: Prevent forced unbinding of Arm SMMU drivers
Date: Tue, 26 Nov 2019 12:27:52 -0800 [thread overview]
Message-ID: <CAGETcx8Hkta6scFdiG=eQypsQ--jrR1YisaOQATCbMiu+aG8sg@mail.gmail.com> (raw)
In-Reply-To: <5c91d467-5e59-482b-8f4f-e0cfa3db9028@huawei.com>
On Tue, Nov 26, 2019 at 1:13 AM John Garry <john.garry@huawei.com> wrote:
>
> On 21/11/2019 11:49, Will Deacon wrote:
> > Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation,
> > since it will likely lead to catastrophic failure for any DMA devices
> > mastering through the SMMU being unbound. When the driver then attempts
> > to "handle" the fatal faults, it's very easy to trip over dead data
> > structures, leading to use-after-free.
> >
> > On John's machine, he reports that the machine was "unusable" due to
> > loss of the storage controller following a forced unbind of the SMMUv3
> > driver:
> >
> > | # cd ./bus/platform/drivers/arm-smmu-v3
> > | # echo arm-smmu-v3.0.auto > unbind
> > | hisi_sas_v2_hw HISI0162:01: CQE_AXI_W_ERR (0x800) found!
> > | platform arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x00000146
> > | [hwprod 0x00000146, hwcons 0x00000000]
> >
> > Prevent this forced unbinding of the drivers by setting "suppress_bind_attrs"
> > to true.
>
> This seems a reasonable approach for now.
>
> BTW, I'll give this series a spin this week, which again looks to be
> your iommu/module branch, excluding the new IORT patch.
Is this on a platform where of_devlink creates device links between
the iommu device and its suppliers? I'm guessing no? Because device
links should for unbinding of all the consumers before unbinding the
supplier.
Looks like it'll still allow the supplier to unbind if the consumers
don't allow unbinding. Is that the case here?
-Saravana
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-11-26 20:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-21 11:49 [PATCH v3 00/14] iommu: Permit modular builds of ARM SMMU[v3] drivers Will Deacon
2019-11-21 11:49 ` [PATCH v3 01/14] drivers/iommu: Export core IOMMU API symbols to permit modular drivers Will Deacon
2019-11-21 11:49 ` [PATCH v3 02/14] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage Will Deacon
2019-11-21 11:49 ` [PATCH v3 03/14] PCI: Export pci_ats_disabled() as a GPL symbol to modules Will Deacon
2019-11-21 11:49 ` [PATCH v3 04/14] drivers/iommu: Take a ref to the IOMMU driver prior to ->add_device() Will Deacon
2019-11-21 11:49 ` [PATCH v3 05/14] iommu/of: Take a ref to the IOMMU driver during ->of_xlate() Will Deacon
2019-11-21 11:49 ` [PATCH v3 06/14] drivers/iommu: Allow IOMMU bus ops to be unregistered Will Deacon
2019-11-21 11:49 ` [PATCH v3 07/14] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" Will Deacon
2019-11-21 11:49 ` [PATCH v3 08/14] Revert "iommu/arm-smmu: Make arm-smmu " Will Deacon
2019-11-21 11:49 ` [PATCH v3 09/14] iommu/arm-smmu: Prevent forced unbinding of Arm SMMU drivers Will Deacon
2019-11-26 9:13 ` John Garry
2019-11-26 20:27 ` Saravana Kannan via iommu [this message]
2019-11-27 11:04 ` John Garry
2019-11-27 11:41 ` John Garry
2019-11-21 11:49 ` [PATCH v3 10/14] iommu/arm-smmu-v3: Unregister IOMMU and bus ops on device removal Will Deacon
2019-11-21 11:49 ` [PATCH v3 11/14] iommu/arm-smmu-v3: Allow building as a module Will Deacon
2019-11-21 11:49 ` [PATCH v3 12/14] iommu/arm-smmu: Unregister IOMMU and bus ops on device removal Will Deacon
2019-11-21 11:49 ` [PATCH v3 13/14] iommu/arm-smmu: Allow building as a module Will Deacon
2019-11-21 11:49 ` [PATCH v3 14/14] iommu/arm-smmu: Update my email address in MODULE_AUTHOR() Will Deacon
2019-11-22 17:41 ` [PATCH] iommu/arm-smmu: support SMMU module probing from the IORT Ard Biesheuvel
2019-11-25 12:16 ` Robin Murphy
2019-11-25 16:04 ` Lorenzo Pieralisi
2019-11-27 16:20 ` John Garry
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='CAGETcx8Hkta6scFdiG=eQypsQ--jrR1YisaOQATCbMiu+aG8sg@mail.gmail.com' \
--to=iommu@lists.linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linuxfoundation.org \
--cc=isaacm@codeaurora.org \
--cc=jean-philippe@linaro.org \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.com \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).