Re: [PATCH 3/3] iommu/uapi: Add helper function for size lookup

[Jacob Pan]

On Wed, 29 Jan 2020 15:19:51 -0700
Alex Williamson <alex.williamson@xxxxxxxxxx> wrote:

> On Wed, 29 Jan 2020 14:40:46 -0700
> Alex Williamson <alex.williamson@xxxxxxxxxx> wrote:
> 
> > On Tue, 28 Jan 2020 22:02:04 -0800
> > Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx> wrote:
> >   
> > > IOMMU UAPI can be extended in the future by adding new
> > > fields at the end of each user data structure. Since we use
> > > a unified UAPI version for compatibility checking, a lookup
> > > function is needed to find the correct user data size to copy
> > > from user.
> > > 
> > > This patch adds a helper function based on a 2D lookup with
> > > version and type as input arguments.
> > > 
> > > Signed-off-by: Liu Yi L <yi.l.liu@xxxxxxxxx>
> > > Signed-off-by: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx>
> > > ---
> > >  drivers/iommu/iommu.c | 22 ++++++++++++++++++++++
> > >  include/linux/iommu.h |  6 ++++++
> > >  2 files changed, 28 insertions(+)
> > > 
> > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > > index 7dd51c5d2ba1..9e5de9abebdf 100644
> > > --- a/drivers/iommu/iommu.c
> > > +++ b/drivers/iommu/iommu.c
> > > @@ -1696,6 +1696,28 @@ int iommu_sva_unbind_gpasid(struct
> > > iommu_domain *domain, struct device *dev, }
> > >  EXPORT_SYMBOL_GPL(iommu_sva_unbind_gpasid);
> > >  
> > > +
> > > +/**
> > > + * Maintain a UAPI version to user data structure size lookup
> > > for each
> > > + * API function types we support. e.g. bind guest pasid, cache
> > > invalidation.
> > > + * As data structures being extended with new members, the
> > > offsetofend()
> > > + * will identify the new sizes.
> > > + */
> > > +const static int
> > > iommu_uapi_data_size[NR_IOMMU_UAPI_TYPE][IOMMU_UAPI_VERSION] = {
> > > +	/* IOMMU_UAPI_BIND_GPASID */
> > > +	{offsetofend(struct iommu_gpasid_bind_data, vtd)},
> > > +	/* IOMMU_UAPI_CACHE_INVAL */
> > > +	{offsetofend(struct iommu_cache_invalidate_info,
> > > addr_info)},  
> 
> This seems prone to errors in future revisions.  Both of the above
> reference the end of fields within an anonymous union.  When a new
> field is added, it's not necessarily the newest field that needs to be
> listed here, but the largest at the time.
> So should the current
> version always use sizeof instead (or name the union so we can
> reference it)?  I'm not sure of an error proof way to make sure we
> keep the N-1 version consistent when we add a new version though.
> More comments?
> 
yes. we must be very careful the new size has to be the largest of the
union not the newest. I agree that using sizeof() would make current
version size straightforward. But we have to find the size for N-1
with offsetofend, seems more risk to the existing N-1 code when bump up
version.

I was thinking this array also serve as documentation of the revision
history, but as you pointed out offsetofend may not be the newest
member of the union. So it cannot document which member was added in
which version. Seems more comments is the only way.

How about comments as below with example future extensions?

/**
 * Maintain a UAPI version to user data structure size lookup for each
 * API function types we support. e.g. bind guest pasid, cache invalidation.
 * As data structures being extended with new members, offsetofend() is
 * used to identify the size. In case of adding a new member to a union,
 * offsetofend() applies to the largest member which may not be the newest.
 *
 * When new types are introduced with new versions, the new types for older
 * version must be filled with -EINVAL.
 *
 * The table below documents UAPI revision history with the name of the
 * newest member of each data structure. The largest member of a union was
 * used for the initial version of each type.
 *
 * Current version: V1
 * +--------------+---------------+
 * | Type /       |       V1      |
 * | UAPI Version |               |
 * +==============+===============+
 * | BIND_GPASID  |       vtd     |
 * +--------------+---------------+
 * | CACHE_INVAL  |  addr_info    |
 * +--------------+---------------+
 * | PAGE_RESP    |  code         |
 * +--------------+---------------+
 *
 * Future extension examples:
 *
 * V2 adds new members to bind_gpasid and cache_invalidate API but not
 * page response.
 * +--------------+---------------+---------------+
 * | Type /       |       V1      |      V2       |
 * | UAPI Version |               |               |
 * +==============+===============+===============+
 * | BIND_GPASID  |       vtd     |      smmu_v3  |
 * +--------------+---------------+---------------+
 * | CACHE_INVAL  |  addr_info    |     new_info  |
 * +--------------+---------------+---------------+
 * | PAGE_RESP    |  code         |     N/A       |
 * +--------------+---------------+---------------+
 *
 * V3 introduces a new UAPI data type: NEW_TYPE but with no new members
 * added to the existing types.
 * +--------------+---------------+---------------+---------------+
 * | Type /       |       V1      |      V2       |      V3       |
 * | UAPI Version |               |               |               |
 * +==============+===============+===============+===============+
 * | BIND_GPASID  |       vtd     |      smmu_v3  |       N/A     |
 * +--------------+---------------+---------------+---------------+
 * | CACHE_INVAL  |  addr_info    |    new_info   |       N/A     |
 * +--------------+---------------+---------------+---------------+
 * | PAGE_RESP    |  code         |    N/A        |       N/A     |
 * +--------------+---------------+---------------+---------------+
 * | NEW_TYPE     |  -EINVAL      |     -EINVAL   | largest_member|
 * +--------------+---------------+---------------+---------------+
 *

> Also, is the 12-bytes of padding in struct iommu_gpasid_bind_data
> excessive with this new versioning scheme?  Per rule #2 I'm not sure
> if we're allowed to repurpose those padding bytes, but if we add
> fields to the end of the structure as the scheme suggests, we're
> stuck with not being able to expand the union for new fields.
> 
> Thanks,
> Alex
> 
> > > +	/* IOMMU_UAPI_PAGE_RESP */
> > > +	{offsetofend(struct iommu_page_response, code)},
> > > +};
> > > +
> > > +int iommu_uapi_get_data_size(int type, int version)
> > > +{    
> > 
> > Seems like this is asking for a bounds check,
> > 
> >   if (type >= NR_IOMMU_UAPI_TYPE || version > IOMMU_UAPI_VERSION)
> >   	return -EINVAL;
> > 
> > If we add new types in future versions, I assume we'd back fill the
> > table with -EINVAL as well (rather than zero).  Thanks,
> > 
> > Alex
> >   
> > > +	return iommu_uapi_data_size[type][version - 1];
> > > +}
> > > +EXPORT_SYMBOL_GPL(iommu_uapi_get_data_size);
> > > +
> > >  static void __iommu_detach_device(struct iommu_domain *domain,
> > >  				  struct device *dev)
> > >  {
> > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > > index 9718c109ea0a..416fe02160ba 100644
> > > --- a/include/linux/iommu.h
> > > +++ b/include/linux/iommu.h
> > > @@ -500,6 +500,7 @@ extern int iommu_report_device_fault(struct
> > > device *dev, struct iommu_fault_event *evt);
> > >  extern int iommu_page_response(struct device *dev,
> > >  			       struct iommu_page_response *msg);
> > > +extern int iommu_uapi_get_data_size(int type, int version);
> > >  
> > >  extern int iommu_group_id(struct iommu_group *group);
> > >  extern struct iommu_group *iommu_group_get_for_dev(struct device
> > > *dev); @@ -885,6 +886,11 @@ static inline int
> > > iommu_page_response(struct device *dev, return -ENODEV;
> > >  }
> > >  
> > > +static int iommu_uapi_get_data_size(int type, int version)
> > > +{
> > > +	return -ENODEV;
> > > +}
> > > +
> > >  static inline int iommu_group_id(struct iommu_group *group)
> > >  {
> > >  	return -ENODEV;    
> >   
> 

[Jacob Pan]