The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions
@ 2023-09-27 14:25 Dawei Li
  2023-09-28  1:33 ` Baolu Lu
  0 siblings, 1 reply; 5+ messages in thread
From: Dawei Li @ 2023-09-27 14:25 UTC (permalink / raw)
  To: joro, will; +Cc: robin.murphy, jgg, iommu, linux-kernel, Dawei Li

In iommu_get_resv_regions(), param list is an argument supplied by caller,
into which callee is supposed to insert resv regions.

In other words, this 'list' argument is expected to be an empty list,
so make an explicit annotation on it.

Signed-off-by: Dawei Li <set_pte_at@outlook.com>
---
 drivers/iommu/iommu.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1ecac2b5c54f..a01c4a7a9d19 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -813,7 +813,7 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
 
 	mutex_lock(&group->mutex);
 	for_each_group_device(group, device) {
-		struct list_head dev_resv_regions;
+		LIST_HEAD(dev_resv_regions);
 
 		/*
 		 * Non-API groups still expose reserved_regions in sysfs,
@@ -822,7 +822,6 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
 		if (!device->dev->iommu)
 			break;
 
-		INIT_LIST_HEAD(&dev_resv_regions);
 		iommu_get_resv_regions(device->dev, &dev_resv_regions);
 		ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
 		iommu_put_resv_regions(device->dev, &dev_resv_regions);
@@ -1061,12 +1060,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
 					       struct device *dev)
 {
 	struct iommu_resv_region *entry;
-	struct list_head mappings;
 	unsigned long pg_size;
+	LIST_HEAD(mappings);
 	int ret = 0;
 
 	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0;
-	INIT_LIST_HEAD(&mappings);
 
 	if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size))
 		return -EINVAL;
@@ -2813,6 +2811,9 @@ void iommu_get_resv_regions(struct device *dev, struct list_head *list)
 {
 	const struct iommu_ops *ops = dev_iommu_ops(dev);
 
+	if (WARN_ON(!list_empty(list)))
+		return;
+
 	if (ops->get_resv_regions)
 		ops->get_resv_regions(dev, list);
 }
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions
  2023-09-27 14:25 [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions Dawei Li
@ 2023-09-28  1:33 ` Baolu Lu
  2023-09-28  8:57   ` Dawei Li
  0 siblings, 1 reply; 5+ messages in thread
From: Baolu Lu @ 2023-09-28  1:33 UTC (permalink / raw)
  To: Dawei Li, joro, will; +Cc: baolu.lu, robin.murphy, jgg, iommu, linux-kernel

On 9/27/23 10:25 PM, Dawei Li wrote:
> In iommu_get_resv_regions(), param list is an argument supplied by caller,
> into which callee is supposed to insert resv regions.
> 
> In other words, this 'list' argument is expected to be an empty list,
> so make an explicit annotation on it.
> 
> Signed-off-by: Dawei Li <set_pte_at@outlook.com>
> ---
>   drivers/iommu/iommu.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 1ecac2b5c54f..a01c4a7a9d19 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -813,7 +813,7 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>   
>   	mutex_lock(&group->mutex);
>   	for_each_group_device(group, device) {
> -		struct list_head dev_resv_regions;
> +		LIST_HEAD(dev_resv_regions);
>   
>   		/*
>   		 * Non-API groups still expose reserved_regions in sysfs,
> @@ -822,7 +822,6 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>   		if (!device->dev->iommu)
>   			break;
>   
> -		INIT_LIST_HEAD(&dev_resv_regions);
>   		iommu_get_resv_regions(device->dev, &dev_resv_regions);
>   		ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
>   		iommu_put_resv_regions(device->dev, &dev_resv_regions);
> @@ -1061,12 +1060,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
>   					       struct device *dev)
>   {
>   	struct iommu_resv_region *entry;
> -	struct list_head mappings;
>   	unsigned long pg_size;
> +	LIST_HEAD(mappings);
>   	int ret = 0;
>   
>   	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0;
> -	INIT_LIST_HEAD(&mappings);
>   
>   	if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size))
>   		return -EINVAL;
> @@ -2813,6 +2811,9 @@ void iommu_get_resv_regions(struct device *dev, struct list_head *list)
>   {
>   	const struct iommu_ops *ops = dev_iommu_ops(dev);
>   
> +	if (WARN_ON(!list_empty(list)))
> +		return;

I don't understand why the input list *must* be empty. This interface
has already been exported, so please update the comment to explain this
new requirement.

> +
>   	if (ops->get_resv_regions)
>   		ops->get_resv_regions(dev, list);
>   }

Best regards,
baolu

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions
  2023-09-28  1:33 ` Baolu Lu
@ 2023-09-28  8:57   ` Dawei Li
  2023-09-28  9:25     ` Baolu Lu
  2023-09-28  9:27     ` Robin Murphy
  0 siblings, 2 replies; 5+ messages in thread
From: Dawei Li @ 2023-09-28  8:57 UTC (permalink / raw)
  To: Baolu Lu; +Cc: joro, will, robin.murphy, jgg, iommu, linux-kernel

Hi,
Thanks for reviewing,

On Thu, Sep 28, 2023 at 09:33:29AM +0800, Baolu Lu wrote:
> On 9/27/23 10:25 PM, Dawei Li wrote:
> > In iommu_get_resv_regions(), param list is an argument supplied by caller,
> > into which callee is supposed to insert resv regions.
> > 
> > In other words, this 'list' argument is expected to be an empty list,
> > so make an explicit annotation on it.
> > 
> > Signed-off-by: Dawei Li <set_pte_at@outlook.com>
> > ---
> >   drivers/iommu/iommu.c | 9 +++++----
> >   1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 1ecac2b5c54f..a01c4a7a9d19 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -813,7 +813,7 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
> >   	mutex_lock(&group->mutex);
> >   	for_each_group_device(group, device) {
> > -		struct list_head dev_resv_regions;
> > +		LIST_HEAD(dev_resv_regions);
> >   		/*
> >   		 * Non-API groups still expose reserved_regions in sysfs,
> > @@ -822,7 +822,6 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
> >   		if (!device->dev->iommu)
> >   			break;
> > -		INIT_LIST_HEAD(&dev_resv_regions);
> >   		iommu_get_resv_regions(device->dev, &dev_resv_regions);
> >   		ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
> >   		iommu_put_resv_regions(device->dev, &dev_resv_regions);
> > @@ -1061,12 +1060,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
> >   					       struct device *dev)
> >   {
> >   	struct iommu_resv_region *entry;
> > -	struct list_head mappings;
> >   	unsigned long pg_size;
> > +	LIST_HEAD(mappings);
> >   	int ret = 0;
> >   	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0;
> > -	INIT_LIST_HEAD(&mappings);
> >   	if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size))
> >   		return -EINVAL;
> > @@ -2813,6 +2811,9 @@ void iommu_get_resv_regions(struct device *dev, struct list_head *list)
> >   {
> >   	const struct iommu_ops *ops = dev_iommu_ops(dev);
> > +	if (WARN_ON(!list_empty(list)))
> > +		return;
> 
> I don't understand why the input list *must* be empty. This interface

Because @list is an output-only argument, which is supposed to be filled                                                                                                       
by caller(inserting elements into it). If it's not empty, it's an inputing                                                                                                     
argument, in which case caller will take existing node (in @list) into account,
and insert new nodes before/after them.                                                                                                                                            
Please lemme put it another way, if list argment is not empty:                                                                                                                 

Before calling:                                                                                                                                                                
list: head->A                                                                                                                                                                  

After calling                                                                                                                                                                  
list: head->A->B->C                                                                                                                                                            

It will confuse caller cuz it can't tell whether A is a valid returned
by callee.

> has already been exported, so please update the comment to explain this
> new requirement.
> 
> > +
> >   	if (ops->get_resv_regions)
> >   		ops->get_resv_regions(dev, list);
> >   }
> 
> Best regards,
> baolu

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions
  2023-09-28  8:57   ` Dawei Li
@ 2023-09-28  9:25     ` Baolu Lu
  2023-09-28  9:27     ` Robin Murphy
  1 sibling, 0 replies; 5+ messages in thread
From: Baolu Lu @ 2023-09-28  9:25 UTC (permalink / raw)
  To: Dawei Li; +Cc: baolu.lu, joro, will, robin.murphy, jgg, iommu, linux-kernel

On 2023/9/28 16:57, Dawei Li wrote:
> On Thu, Sep 28, 2023 at 09:33:29AM +0800, Baolu Lu wrote:
>> On 9/27/23 10:25 PM, Dawei Li wrote:
>>> In iommu_get_resv_regions(), param list is an argument supplied by caller,
>>> into which callee is supposed to insert resv regions.
>>>
>>> In other words, this 'list' argument is expected to be an empty list,
>>> so make an explicit annotation on it.
>>>
>>> Signed-off-by: Dawei Li<set_pte_at@outlook.com>
>>> ---
>>>    drivers/iommu/iommu.c | 9 +++++----
>>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 1ecac2b5c54f..a01c4a7a9d19 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -813,7 +813,7 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>>>    	mutex_lock(&group->mutex);
>>>    	for_each_group_device(group, device) {
>>> -		struct list_head dev_resv_regions;
>>> +		LIST_HEAD(dev_resv_regions);
>>>    		/*
>>>    		 * Non-API groups still expose reserved_regions in sysfs,
>>> @@ -822,7 +822,6 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>>>    		if (!device->dev->iommu)
>>>    			break;
>>> -		INIT_LIST_HEAD(&dev_resv_regions);
>>>    		iommu_get_resv_regions(device->dev, &dev_resv_regions);
>>>    		ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
>>>    		iommu_put_resv_regions(device->dev, &dev_resv_regions);
>>> @@ -1061,12 +1060,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
>>>    					       struct device *dev)
>>>    {
>>>    	struct iommu_resv_region *entry;
>>> -	struct list_head mappings;
>>>    	unsigned long pg_size;
>>> +	LIST_HEAD(mappings);
>>>    	int ret = 0;
>>>    	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0;
>>> -	INIT_LIST_HEAD(&mappings);
>>>    	if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size))
>>>    		return -EINVAL;
>>> @@ -2813,6 +2811,9 @@ void iommu_get_resv_regions(struct device *dev, struct list_head *list)
>>>    {
>>>    	const struct iommu_ops *ops = dev_iommu_ops(dev);
>>> +	if (WARN_ON(!list_empty(list)))
>>> +		return;
>> I don't understand why the input list*must*  be empty. This interface
> Because @list is an output-only argument, which is supposed to be filled
> by caller(inserting elements into it). If it's not empty, it's an inputing
> argument, in which case caller will take existing node (in @list) into account,
> and insert new nodes before/after them.
> Please lemme put it another way, if list argment is not empty:
> 
> Before calling:
> list: head->A
> 
> After calling
> list: head->A->B->C
> 
> It will confuse caller cuz it can't tell whether A is a valid returned
> by callee.

I see. Thank you for the explanation.

Best regards,
baolu


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions
  2023-09-28  8:57   ` Dawei Li
  2023-09-28  9:25     ` Baolu Lu
@ 2023-09-28  9:27     ` Robin Murphy
  1 sibling, 0 replies; 5+ messages in thread
From: Robin Murphy @ 2023-09-28  9:27 UTC (permalink / raw)
  To: Dawei Li, Baolu Lu; +Cc: joro, will, jgg, iommu, linux-kernel

On 2023-09-28 09:57, Dawei Li wrote:
> Hi,
> Thanks for reviewing,
> 
> On Thu, Sep 28, 2023 at 09:33:29AM +0800, Baolu Lu wrote:
>> On 9/27/23 10:25 PM, Dawei Li wrote:
>>> In iommu_get_resv_regions(), param list is an argument supplied by caller,
>>> into which callee is supposed to insert resv regions.
>>>
>>> In other words, this 'list' argument is expected to be an empty list,
>>> so make an explicit annotation on it.
>>>
>>> Signed-off-by: Dawei Li <set_pte_at@outlook.com>
>>> ---
>>>    drivers/iommu/iommu.c | 9 +++++----
>>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 1ecac2b5c54f..a01c4a7a9d19 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -813,7 +813,7 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>>>    	mutex_lock(&group->mutex);
>>>    	for_each_group_device(group, device) {
>>> -		struct list_head dev_resv_regions;
>>> +		LIST_HEAD(dev_resv_regions);
>>>    		/*
>>>    		 * Non-API groups still expose reserved_regions in sysfs,
>>> @@ -822,7 +822,6 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>>>    		if (!device->dev->iommu)
>>>    			break;
>>> -		INIT_LIST_HEAD(&dev_resv_regions);
>>>    		iommu_get_resv_regions(device->dev, &dev_resv_regions);
>>>    		ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
>>>    		iommu_put_resv_regions(device->dev, &dev_resv_regions);
>>> @@ -1061,12 +1060,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
>>>    					       struct device *dev)
>>>    {
>>>    	struct iommu_resv_region *entry;
>>> -	struct list_head mappings;
>>>    	unsigned long pg_size;
>>> +	LIST_HEAD(mappings);
>>>    	int ret = 0;
>>>    	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0;
>>> -	INIT_LIST_HEAD(&mappings);
>>>    	if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size))
>>>    		return -EINVAL;
>>> @@ -2813,6 +2811,9 @@ void iommu_get_resv_regions(struct device *dev, struct list_head *list)
>>>    {
>>>    	const struct iommu_ops *ops = dev_iommu_ops(dev);
>>> +	if (WARN_ON(!list_empty(list)))
>>> +		return;
>>
>> I don't understand why the input list *must* be empty. This interface

Yeah, the commit message really doesn't make much sense :(

> Because @list is an output-only argument, which is supposed to be filled
> by caller(inserting elements into it). If it's not empty, it's an inputing
> argument, in which case caller will take existing node (in @list) into account,
> and insert new nodes before/after them.
> Please lemme put it another way, if list argment is not empty:
> 
> Before calling:
> list: head->A
> 
> After calling
> list: head->A->B->C
> 
> It will confuse caller cuz it can't tell whether A is a valid returned
> by callee.

If a caller would be confused by appending to a non-empty list then that 
caller should avoid passing a non-empty list. But that's not the API's 
problem; in general, appending to non-empty lists is absolutely a valid 
thing to do, it's kind of the point of using a list rather than, say, 
returning an array. It seems entirely reasonable that a caller might 
want to collect the reserved regions for multiple groups into a single 
list for its own convenience, and we have absolutely no reason to 
disallow that.

Note also that your arbitrary input vs. output argument rule 
fundamentally couldn't work for this API, since actual implementations 
of ops->get_resv_regions already *do* build up the list by passing it 
around multiple different helper APIs internally (look at the call path 
through arm_smmu_get_resv_regions(), for instance).

Thanks,
Robin.

>> has already been exported, so please update the comment to explain this
>> new requirement.
>>
>>> +
>>>    	if (ops->get_resv_regions)
>>>    		ops->get_resv_regions(dev, list);
>>>    }
>>
>> Best regards,
>> baolu

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-09-28  9:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-09-27 14:25 [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions Dawei Li
2023-09-28  1:33 ` Baolu Lu
2023-09-28  8:57   ` Dawei Li
2023-09-28  9:25     ` Baolu Lu
2023-09-28  9:27     ` Robin Murphy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox