On Tue, Feb 08, 2022 at 09:25:56AM +0800, Lu Baolu wrote: > The common iommu_ops is hooked to both device and domain. When a helper > has both device and domain pointer, the way to get the iommu_ops looks > messy in iommu core. This sorts out the way to get iommu_ops. The device > related helpers go through device pointer, while the domain related ones > go through domain pointer. > > Signed-off-by: Lu Baolu <[email protected]> > --- > include/linux/iommu.h | 14 ++++++++++++++ > drivers/iommu/iommu.c | 20 +++++++++++--------- > 2 files changed, 25 insertions(+), 9 deletions(-) > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 9ffa2e88f3d0..eb2684f95018 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -381,6 +381,20 @@ static inline void iommu_iotlb_gather_init(struct > iommu_iotlb_gather *gather) > }; > } > > +static inline const struct iommu_ops *dev_iommu_ops(struct device *dev) > +{ > + /* > + * Assume that valid ops must be installed if iommu_probe_device() > + * has succeeded. The device ops are essentially for internal use > + * within the IOMMU subsystem itself, so we should be able to trust > + * ourselves not to misuse the helper. > + */ > + WARN_ON(!dev || !dev->iommu || !dev->iommu->iommu_dev || > + !dev->iommu->iommu_dev->ops);
IMHO this is overzealous. The kernel will reliably crash on null dereference here, I'm not sure this adds much. But either way: Reviewed-by: Jason Gunthorpe <[email protected]> Jason _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
