[PATCH kernel v9 14/32] powerpc/iommu: Fix IOMMU ownership control functions

[David Gibson]

On Sat, Apr 25, 2015 at 10:14:38PM +1000, Alexey Kardashevskiy wrote:
> This adds missing locks in iommu_take_ownership()/
> iommu_release_ownership().
> 
> This marks all pages busy in iommu_table::it_map in order to catch
> errors if there is an attempt to use this table while ownership over it
> is taken.
> 
> This only clears TCE content if there is no page marked busy in it_map.
> Clearing must be done outside of the table locks as iommu_clear_tce()
> called from iommu_clear_tces_and_put_pages() does this.
> 
> In order to use bitmap_empty(), the existing code clears bit#0 which
> is set even in an empty table if it is bus-mapped at 0 as
> iommu_init_table() reserves page#0 to prevent buggy drivers
> from crashing when allocated page is bus-mapped at zero
> (which is correct). This restores the bit in the case of failure
> to bring the it_map to the state it was in when we called
> iommu_take_ownership().

Ah! I finally understand what all this bit#0 stuff is about.  Thanks
for the explanation.

> 
> Signed-off-by: Alexey Kardashevskiy <aik at ozlabs.ru>

Reviewed-by: David Gibson <david at gibson.dropbear.id.au>

With one small comment..


> ---
> Changes:
> v9:
> * iommu_table_take_ownership() did not return @ret (and ignored EBUSY),
> now it does return correct error.
> * updated commit log about setting bit#0 in the case of failure
> 
> v5:
> * do not store bit#0 value, it has to be set for zero-based table
> anyway
> * removed test_and_clear_bit
> ---
>  arch/powerpc/kernel/iommu.c | 31 +++++++++++++++++++++++++------
>  1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 2856d27..ea2c8ba 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -1045,32 +1045,51 @@ EXPORT_SYMBOL_GPL(iommu_tce_build);
>  
>  int iommu_take_ownership(struct iommu_table *tbl)
>  {
> -	unsigned long sz = (tbl->it_size + 7) >> 3;
> +	unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
> +	int ret = 0;
> +
> +	spin_lock_irqsave(&tbl->large_pool.lock, flags);
> +	for (i = 0; i < tbl->nr_pools; i++)
> +		spin_lock(&tbl->pools[i].lock);

>  	if (tbl->it_offset == 0)
>  		clear_bit(0, tbl->it_map);
>  
>  	if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
>  		pr_err("iommu_tce: it_map is not empty");
> -		return -EBUSY;
> +		ret = -EBUSY;
> +		/* Restore bit#0 set by iommu_init_table() */
> +		if (tbl->it_offset == 0)
> +			set_bit(0, tbl->it_map);
> +	} else {
> +		memset(tbl->it_map, 0xff, sz);
>  	}
>  
> -	memset(tbl->it_map, 0xff, sz);
> +	for (i = 0; i < tbl->nr_pools; i++)
> +		spin_unlock(&tbl->pools[i].lock);

I *think* it's safe in this case, but releasing locks not in the
reverse order you acquired them makes me a bit nervous.

> +	spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
>  
> -
> -	return 0;
> +	return ret;
>  }
>  EXPORT_SYMBOL_GPL(iommu_take_ownership);
>  
>  void iommu_release_ownership(struct iommu_table *tbl)
>  {
> -	unsigned long sz = (tbl->it_size + 7) >> 3;
> +	unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
> +
> +	spin_lock_irqsave(&tbl->large_pool.lock, flags);
> +	for (i = 0; i < tbl->nr_pools; i++)
> +		spin_lock(&tbl->pools[i].lock);
>  
>  	memset(tbl->it_map, 0, sz);
>  
>  	/* Restore bit#0 set by iommu_init_table() */
>  	if (tbl->it_offset == 0)
>  		set_bit(0, tbl->it_map);
> +
> +	for (i = 0; i < tbl->nr_pools; i++)
> +		spin_unlock(&tbl->pools[i].lock);
> +	spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(iommu_release_ownership);
>  

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20150429/a6f2d42d/attachment-0001.sig>