From: Joerg Roedel <joro@8bytes.org>
To: Will Deacon <will@kernel.org>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Robin Murphy <robin.murphy@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Subject: Re: [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module
Date: Tue, 5 Nov 2019 13:15:08 +0100 [thread overview]
Message-ID: <20191105121508.GA3479@8bytes.org> (raw)
In-Reply-To: <20191031154247.GB28061@willie-the-truck>
Hi Will,
On Thu, Oct 31, 2019 at 03:42:47PM +0000, Will Deacon wrote:
> Generally, I think unloading the IOMMU driver module while there are
> active users is a pretty bad idea, much like unbinding the driver via
> /sys in the same situation would also be fairly daft. However, I *think*
> the code in __device_release_driver() tries to deal with this by
> iterating over the active consumers and ->remove()ing them first.
>
> I'm without hardware access at the moment, so I haven't been able to
> test this myself. We could nobble the module_exit() hook, but there's
> still the "force unload" option depending on the .config.
Okay, but besides the force-unload case, can we prevent accidential
unloading by taking a reference to the module in add_device() and release
it in remove_device()?
Regards,
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Will Deacon <will@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
iommu@lists.linux-foundation.org,
Robin Murphy <robin.murphy@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module
Date: Tue, 5 Nov 2019 13:15:08 +0100 [thread overview]
Message-ID: <20191105121508.GA3479@8bytes.org> (raw)
In-Reply-To: <20191031154247.GB28061@willie-the-truck>
Hi Will,
On Thu, Oct 31, 2019 at 03:42:47PM +0000, Will Deacon wrote:
> Generally, I think unloading the IOMMU driver module while there are
> active users is a pretty bad idea, much like unbinding the driver via
> /sys in the same situation would also be fairly daft. However, I *think*
> the code in __device_release_driver() tries to deal with this by
> iterating over the active consumers and ->remove()ing them first.
>
> I'm without hardware access at the moment, so I haven't been able to
> test this myself. We could nobble the module_exit() hook, but there's
> still the "force unload" option depending on the .config.
Okay, but besides the force-unload case, can we prevent accidential
unloading by taking a reference to the module in add_device() and release
it in remove_device()?
Regards,
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-11-05 12:15 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 14:51 [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 14:51 ` [PATCH 1/7] drivers/iommu: Export core IOMMU API symbols to permit modular drivers Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 14:51 ` [PATCH 2/7] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 14:51 ` [PATCH 3/7] PCI: Export pci_ats_disabled() as a GPL symbol to modules Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 20:30 ` Bjorn Helgaas
2019-10-30 20:30 ` Bjorn Helgaas
2019-10-30 14:51 ` [PATCH 4/7] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 14:51 ` [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 19:31 ` Joerg Roedel
2019-10-30 19:31 ` Joerg Roedel
2019-10-31 15:42 ` Will Deacon
2019-10-31 15:42 ` Will Deacon
2019-11-04 19:15 ` Jean-Philippe Brucker
2019-11-04 19:15 ` Jean-Philippe Brucker
2019-11-08 14:54 ` Will Deacon
2019-11-08 14:54 ` Will Deacon
2019-11-05 12:15 ` Joerg Roedel [this message]
2019-11-05 12:15 ` Joerg Roedel
2019-11-08 11:03 ` Will Deacon
2019-11-08 11:03 ` Will Deacon
2019-10-30 14:51 ` [PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular" Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 23:09 ` Jordan Crouse
2019-10-30 23:09 ` Jordan Crouse
2019-10-31 12:03 ` Will Deacon
2019-10-31 12:03 ` Will Deacon
2019-10-31 15:32 ` Jordan Crouse
2019-10-31 15:32 ` Jordan Crouse
2019-10-30 14:51 ` [PATCH 7/7] iommu/arm-smmu: Allow building as a module Will Deacon
2019-10-30 14:51 ` Will Deacon
2019-10-30 15:22 ` Rob Herring
2019-10-30 15:22 ` Rob Herring
2019-10-30 15:26 ` Will Deacon
2019-10-30 15:26 ` Will Deacon
2019-10-30 15:33 ` Robin Murphy
2019-10-30 15:33 ` Robin Murphy
2019-11-04 19:34 ` Isaac J. Manjarres
2019-11-04 19:34 ` Isaac J. Manjarres
2019-11-07 12:48 ` Will Deacon
2019-11-07 12:48 ` Will Deacon
2019-10-30 15:35 ` [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Robin Murphy
2019-10-30 15:35 ` Robin Murphy
2019-10-30 15:54 ` Will Deacon
2019-10-30 15:54 ` Will Deacon
2019-10-31 0:57 ` Saravana Kannan
2019-10-31 0:57 ` Saravana Kannan via iommu
2019-10-31 19:37 ` Jean-Philippe Brucker
2019-10-31 19:37 ` Jean-Philippe Brucker
2019-10-31 23:34 ` Saravana Kannan
2019-10-31 23:34 ` Saravana Kannan via iommu
2019-11-01 10:27 ` John Garry
2019-11-01 10:27 ` John Garry
2019-11-01 21:13 ` Saravana Kannan
2019-11-01 21:13 ` Saravana Kannan via iommu
2019-11-04 12:16 ` John Garry
2019-11-04 12:16 ` John Garry
2019-11-04 13:29 ` Robin Murphy
2019-11-04 13:29 ` Robin Murphy
2019-11-07 6:11 ` Saravana Kannan
2019-11-07 6:11 ` Saravana Kannan via iommu
2019-11-07 9:13 ` Jean-Philippe Brucker
2019-11-07 9:13 ` Jean-Philippe Brucker
2019-11-07 6:02 ` Saravana Kannan
2019-11-07 6:02 ` Saravana Kannan via iommu
2019-11-01 11:41 ` Jean-Philippe Brucker
2019-11-01 11:41 ` Jean-Philippe Brucker
2019-11-01 12:28 ` Lorenzo Pieralisi
2019-11-01 12:28 ` Lorenzo Pieralisi
2019-11-01 21:26 ` Saravana Kannan
2019-11-01 21:26 ` Saravana Kannan via iommu
2019-11-04 11:43 ` Lorenzo Pieralisi
2019-11-04 11:43 ` Lorenzo Pieralisi
2019-11-07 5:55 ` Saravana Kannan
2019-11-07 5:55 ` Saravana Kannan via iommu
2019-11-01 17:21 ` Will Deacon
2019-11-01 17:21 ` Will Deacon
2019-11-04 7:54 ` Jean-Philippe Brucker
2019-11-04 7:54 ` Jean-Philippe Brucker
2019-11-07 6:16 ` Saravana Kannan
2019-11-07 6:16 ` Saravana Kannan via iommu
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=20191105121508.GA3479@8bytes.org \
--to=joro@8bytes.org \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=robin.murphy@arm.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 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.