From: Will Deacon <will@kernel.org>
To: John Garry <john.garry@huawei.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
"Isaac J. Manjarres" <isaacm@codeaurora.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Saravana Kannan <saravanak@google.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2 6/9] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular"
Date: Fri, 8 Nov 2019 17:48:46 +0000 [thread overview]
Message-ID: <20191108174846.GA22677@willie-the-truck> (raw)
In-Reply-To: <20191108173248.GA22448@willie-the-truck>
On Fri, Nov 08, 2019 at 05:32:48PM +0000, Will Deacon wrote:
> On Fri, Nov 08, 2019 at 05:25:09PM +0000, John Garry wrote:
> > On 08/11/2019 16:47, Will Deacon wrote:
> > > On Fri, Nov 08, 2019 at 04:44:25PM +0000, John Garry wrote:
> > > > BTW, it now looks like it was your v1 series I was testing there, on your
> > > > branch iommu/module. It would be helpful to update for ease of testing.
> > >
> > > Yes, sorry about that. I'll update it now (although I'm not sure it will
> > > help with this -- I was going to see what happens with other devices such
> > > as the intel-iommu or storage controllers)
> >
> > So I tried your v2 series for this - it has the same issue, as I
> > anticipated.
>
> Right, I'm just not sure how resilient drivers are expected to be to force
> unbinding like this. You can break lots of stuff with root...
>
> > It seems that some iommu drivers do call iommu_device_register(), so maybe a
> > decent reference. Or simply stop the driver being unbound.
>
> I'm not sure what you mean about iommu_device_register() (we call that
> already), but I guess we can keep the '.suppress_bind_attrs = true' if
> necessary. I'll have a play on my laptop and see how well that works if
> you start unbinding stuff.
So unbinding the nvme driver goes bang:
[90139.090158] nvme nvme0: failed to set APST feature (-19)
[90141.966780] Aborting journal on device dm-1-8.
[90141.967124] Buffer I/O error on dev dm-1, logical block 26247168, lost sync page write
[90141.967169] JBD2: Error -5 detected when updating journal superblock for dm-1-8.
[90141.967403] Buffer I/O error on dev dm-1, logical block 0, lost sync page write
[90141.967454] EXT4-fs (dm-1): I/O error while writing superblock
[90141.967467] EXT4-fs error (device dm-1): ext4_journal_check_start:61: Detected aborted journal
[90141.967473] EXT4-fs (dm-1): Remounting filesystem read-only
[90141.967569] Buffer I/O error on dev dm-1, logical block 0, lost sync page write
[90141.967682] EXT4-fs (dm-1): I/O error while writing superblock
and I've not managed to recover the thing yet (it's stuck trying to reboot.)
What state was your system in after unbinding the SMMU?
Will
next prev parent reply other threads:[~2019-11-08 17:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 15:15 [PATCH v2 0/9] iommu: Permit modular builds of ARM SMMU[v3] drivers Will Deacon
2019-11-08 15:16 ` [PATCH v2 1/9] drivers/iommu: Export core IOMMU API symbols to permit modular drivers Will Deacon
2019-11-08 15:16 ` [PATCH v2 2/9] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage Will Deacon
2019-11-08 15:16 ` [PATCH v2 3/9] PCI: Export pci_ats_disabled() as a GPL symbol to modules Will Deacon
2019-11-08 15:16 ` [PATCH v2 4/9] drivers/iommu: Take a ref to the IOMMU driver prior to ->add_device() Will Deacon
2019-11-08 15:16 ` [PATCH v2 5/9] iommu/of: Take a ref to the IOMMU driver during ->of_xlate() Will Deacon
2019-11-08 15:16 ` [PATCH v2 6/9] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" Will Deacon
2019-11-08 16:17 ` John Garry
2019-11-08 16:44 ` John Garry
2019-11-08 16:47 ` Will Deacon
2019-11-08 17:25 ` John Garry
2019-11-08 17:32 ` Will Deacon
2019-11-08 17:48 ` Will Deacon [this message]
2019-11-08 18:00 ` John Garry
2019-11-08 17:49 ` John Garry
2019-11-08 15:16 ` [PATCH v2 7/9] iommu/arm-smmu-v3: Allow building as a module Will Deacon
2019-11-08 15:16 ` [PATCH v2 8/9] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular" Will Deacon
2019-11-08 15:16 ` [PATCH v2 9/9] iommu/arm-smmu: Allow building as a module 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=20191108174846.GA22677@willie-the-truck \
--to=will@kernel.org \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux-foundation.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 \
/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).