Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
On Mon, Nov 21, 2022 at 10:24 AM Christian König wrote: > > Hi Dawei, > > from the technical description, coding style etc.. it looks clean to me, > but I'm the completely wrong person to ask for a background check. > > I have a high level understanding of how dma-heaps work, but not a > single line of this code is from me. > > Feel free to add my Acked-by, but Laura, John and others do you have any > opinion? No objection from me. Thanks Dawei for submitting this improvement! Acked-by: John Stultz thanks -john
Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
Hi Dawei Li,
On Mon, 21 Nov 2022 at 23:53, Christian König wrote:
>
> Hi Dawei,
>
> from the technical description, coding style etc.. it looks clean to me,
> but I'm the completely wrong person to ask for a background check.
>
> I have a high level understanding of how dma-heaps work, but not a
> single line of this code is from me.
>
> Feel free to add my Acked-by, but Laura, John and others do you have any
> opinion?
>
> Regards,
> Christian.
>
> Am 21.11.22 um 16:28 schrieb Dawei Li:
> > On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:
> >
> > Hi Christian,
> > May I have your opinion on this change?
> >
> > Thanks,
> > Dawei
> >
> >> Racing conflict could be:
> >> task A task B
> >> list_for_each_entry
> >> strcmp(h->name))
> >> list_for_each_entry
> >> strcmp(h->name)
> >> kzallockzalloc
> >> .. .
> >> device_create device_create
> >> list_add
> >> list_add
> >>
> >> The root cause is that task B has no idea about the fact someone
> >> else(A) has inserted heap with same name when it calls list_add,
> >> so a potential collision occurs.
> >>
> >> Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
> >> Signed-off-by: Dawei Li
Looks good to me as well. I will apply it over on drm-misc.
Best,
Sumit.
> >> ---
> >> v1:
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2FTYCP286MB2323950197F60FC3473123B7CA349%40TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C1989f31257fc458a27c508dacbd5078e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046413707443203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OWPUPrIHGnzwXyQE4WlIthThwSuSK2y3Eq2Wq5zAzbo%3Dreserved=0
> >> v1->v2: Narrow down locking scope, check the existence of heap before
> >> insertion, as suggested by Andrew Davis.
> >> v2->v3: Remove double checking.
> >> v3->v4: Minor coding style and patch formatting adjustment.
> >> ---
> >> drivers/dma-buf/dma-heap.c | 28 +++-
> >> 1 file changed, 15 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> >> index 8f5848aa144f..59d158873f4c 100644
> >> --- a/drivers/dma-buf/dma-heap.c
> >> +++ b/drivers/dma-buf/dma-heap.c
> >> @@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct
> >> dma_heap_export_info *exp_info)
> >> return ERR_PTR(-EINVAL);
> >> }
> >>
> >> -/* check the name is unique */
> >> -mutex_lock(_list_lock);
> >> -list_for_each_entry(h, _list, list) {
> >> -if (!strcmp(h->name, exp_info->name)) {
> >> -mutex_unlock(_list_lock);
> >> -pr_err("dma_heap: Already registered heap named %s\n",
> >> - exp_info->name);
> >> -return ERR_PTR(-EINVAL);
> >> -}
> >> -}
> >> -mutex_unlock(_list_lock);
> >> -
> >> heap = kzalloc(sizeof(*heap), GFP_KERNEL);
> >> if (!heap)
> >> return ERR_PTR(-ENOMEM);
> >> @@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct
> >> dma_heap_export_info *exp_info)
> >> err_ret = ERR_CAST(dev_ret);
> >> goto err2;
> >> }
> >> -/* Add heap to the list */
> >> +
> >> mutex_lock(_list_lock);
> >> +/* check the name is unique */
> >> +list_for_each_entry(h, _list, list) {
> >> +if (!strcmp(h->name, exp_info->name)) {
> >> +mutex_unlock(_list_lock);
> >> +pr_err("dma_heap: Already registered heap named %s\n",
> >> + exp_info->name);
> >> +err_ret = ERR_PTR(-EINVAL);
> >> +goto err3;
> >> +}
> >> +}
> >> +
> >> +/* Add heap to the list */
> >> list_add(>list, _list);
> >> mutex_unlock(_list_lock);
> >>
> >> return heap;
> >>
> >> +err3:
> >> +device_destroy(dma_heap_class, heap->heap_devt);
> >> err2:
> >> cdev_del(>heap_cdev);
> >> err1:
> >> --
> >> 2.25.1
> >>
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
Hi Dawei,
from the technical description, coding style etc.. it looks clean to me,
but I'm the completely wrong person to ask for a background check.
I have a high level understanding of how dma-heaps work, but not a
single line of this code is from me.
Feel free to add my Acked-by, but Laura, John and others do you have any
opinion?
Regards,
Christian.
Am 21.11.22 um 16:28 schrieb Dawei Li:
On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:
Hi Christian,
May I have your opinion on this change?
Thanks,
Dawei
Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create device_create
list_add
list_add
The root cause is that task B has no idea about the fact someone
else(A) has inserted heap with same name when it calls list_add,
so a potential collision occurs.
Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
Signed-off-by: Dawei Li
---
v1:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2FTYCP286MB2323950197F60FC3473123B7CA349%40TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C1989f31257fc458a27c508dacbd5078e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046413707443203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OWPUPrIHGnzwXyQE4WlIthThwSuSK2y3Eq2Wq5zAzbo%3Dreserved=0
v1->v2: Narrow down locking scope, check the existence of heap before
insertion, as suggested by Andrew Davis.
v2->v3: Remove double checking.
v3->v4: Minor coding style and patch formatting adjustment.
---
drivers/dma-buf/dma-heap.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 8f5848aa144f..59d158873f4c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
- /* check the name is unique */
- mutex_lock(_list_lock);
- list_for_each_entry(h, _list, list) {
- if (!strcmp(h->name, exp_info->name)) {
- mutex_unlock(_list_lock);
- pr_err("dma_heap: Already registered heap named %s\n",
- exp_info->name);
- return ERR_PTR(-EINVAL);
- }
- }
- mutex_unlock(_list_lock);
-
heap = kzalloc(sizeof(*heap), GFP_KERNEL);
if (!heap)
return ERR_PTR(-ENOMEM);
@@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
err_ret = ERR_CAST(dev_ret);
goto err2;
}
- /* Add heap to the list */
+
mutex_lock(_list_lock);
+ /* check the name is unique */
+ list_for_each_entry(h, _list, list) {
+ if (!strcmp(h->name, exp_info->name)) {
+ mutex_unlock(_list_lock);
+ pr_err("dma_heap: Already registered heap named %s\n",
+ exp_info->name);
+ err_ret = ERR_PTR(-EINVAL);
+ goto err3;
+ }
+ }
+
+ /* Add heap to the list */
list_add(>list, _list);
mutex_unlock(_list_lock);
return heap;
+err3:
+ device_destroy(dma_heap_class, heap->heap_devt);
err2:
cdev_del(>heap_cdev);
err1:
--
2.25.1
Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:
Hi Christian,
May I have your opinion on this change?
Thanks,
Dawei
> Racing conflict could be:
> task A task B
> list_for_each_entry
> strcmp(h->name))
>list_for_each_entry
>strcmp(h->name)
> kzallockzalloc
> .. .
> device_create device_create
> list_add
>list_add
>
> The root cause is that task B has no idea about the fact someone
> else(A) has inserted heap with same name when it calls list_add,
> so a potential collision occurs.
>
> Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
> Signed-off-by: Dawei Li
> ---
> v1:
> https://lore.kernel.org/all/tycp286mb2323950197f60fc3473123b7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
> v1->v2: Narrow down locking scope, check the existence of heap before
> insertion, as suggested by Andrew Davis.
> v2->v3: Remove double checking.
> v3->v4: Minor coding style and patch formatting adjustment.
> ---
> drivers/dma-buf/dma-heap.c | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index 8f5848aa144f..59d158873f4c 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> return ERR_PTR(-EINVAL);
> }
>
> - /* check the name is unique */
> - mutex_lock(_list_lock);
> - list_for_each_entry(h, _list, list) {
> - if (!strcmp(h->name, exp_info->name)) {
> - mutex_unlock(_list_lock);
> - pr_err("dma_heap: Already registered heap named %s\n",
> -exp_info->name);
> - return ERR_PTR(-EINVAL);
> - }
> - }
> - mutex_unlock(_list_lock);
> -
> heap = kzalloc(sizeof(*heap), GFP_KERNEL);
> if (!heap)
> return ERR_PTR(-ENOMEM);
> @@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> err_ret = ERR_CAST(dev_ret);
> goto err2;
> }
> - /* Add heap to the list */
> +
> mutex_lock(_list_lock);
> + /* check the name is unique */
> + list_for_each_entry(h, _list, list) {
> + if (!strcmp(h->name, exp_info->name)) {
> + mutex_unlock(_list_lock);
> + pr_err("dma_heap: Already registered heap named %s\n",
> +exp_info->name);
> + err_ret = ERR_PTR(-EINVAL);
> + goto err3;
> + }
> + }
> +
> + /* Add heap to the list */
> list_add(>list, _list);
> mutex_unlock(_list_lock);
>
> return heap;
>
> +err3:
> + device_destroy(dma_heap_class, heap->heap_devt);
> err2:
> cdev_del(>heap_cdev);
> err1:
> --
> 2.25.1
>
Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
On 11/4/22 11:05 AM, Dawei Li wrote:
Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create device_create
list_add
list_add
The root cause is that task B has no idea about the fact someone
else(A) has inserted heap with same name when it calls list_add,
so a potential collision occurs.
Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
Signed-off-by: Dawei Li
LGTM, Thanks,
Acked-by: Andrew Davis
---
v1:
https://lore.kernel.org/all/tycp286mb2323950197f60fc3473123b7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
v1->v2: Narrow down locking scope, check the existence of heap before
insertion, as suggested by Andrew Davis.
v2->v3: Remove double checking.
v3->v4: Minor coding style and patch formatting adjustment.
---
drivers/dma-buf/dma-heap.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 8f5848aa144f..59d158873f4c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
- /* check the name is unique */
- mutex_lock(_list_lock);
- list_for_each_entry(h, _list, list) {
- if (!strcmp(h->name, exp_info->name)) {
- mutex_unlock(_list_lock);
- pr_err("dma_heap: Already registered heap named %s\n",
- exp_info->name);
- return ERR_PTR(-EINVAL);
- }
- }
- mutex_unlock(_list_lock);
-
heap = kzalloc(sizeof(*heap), GFP_KERNEL);
if (!heap)
return ERR_PTR(-ENOMEM);
@@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
err_ret = ERR_CAST(dev_ret);
goto err2;
}
- /* Add heap to the list */
+
mutex_lock(_list_lock);
+ /* check the name is unique */
+ list_for_each_entry(h, _list, list) {
+ if (!strcmp(h->name, exp_info->name)) {
+ mutex_unlock(_list_lock);
+ pr_err("dma_heap: Already registered heap named %s\n",
+ exp_info->name);
+ err_ret = ERR_PTR(-EINVAL);
+ goto err3;
+ }
+ }
+
+ /* Add heap to the list */
list_add(>list, _list);
mutex_unlock(_list_lock);
return heap;
+err3:
+ device_destroy(dma_heap_class, heap->heap_devt);
err2:
cdev_del(>heap_cdev);
err1:
[PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create device_create
list_add
list_add
The root cause is that task B has no idea about the fact someone
else(A) has inserted heap with same name when it calls list_add,
so a potential collision occurs.
Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
Signed-off-by: Dawei Li
---
v1:
https://lore.kernel.org/all/tycp286mb2323950197f60fc3473123b7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
v1->v2: Narrow down locking scope, check the existence of heap before
insertion, as suggested by Andrew Davis.
v2->v3: Remove double checking.
v3->v4: Minor coding style and patch formatting adjustment.
---
drivers/dma-buf/dma-heap.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 8f5848aa144f..59d158873f4c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
- /* check the name is unique */
- mutex_lock(_list_lock);
- list_for_each_entry(h, _list, list) {
- if (!strcmp(h->name, exp_info->name)) {
- mutex_unlock(_list_lock);
- pr_err("dma_heap: Already registered heap named %s\n",
- exp_info->name);
- return ERR_PTR(-EINVAL);
- }
- }
- mutex_unlock(_list_lock);
-
heap = kzalloc(sizeof(*heap), GFP_KERNEL);
if (!heap)
return ERR_PTR(-ENOMEM);
@@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
err_ret = ERR_CAST(dev_ret);
goto err2;
}
- /* Add heap to the list */
+
mutex_lock(_list_lock);
+ /* check the name is unique */
+ list_for_each_entry(h, _list, list) {
+ if (!strcmp(h->name, exp_info->name)) {
+ mutex_unlock(_list_lock);
+ pr_err("dma_heap: Already registered heap named %s\n",
+ exp_info->name);
+ err_ret = ERR_PTR(-EINVAL);
+ goto err3;
+ }
+ }
+
+ /* Add heap to the list */
list_add(>list, _list);
mutex_unlock(_list_lock);
return heap;
+err3:
+ device_destroy(dma_heap_class, heap->heap_devt);
err2:
cdev_del(>heap_cdev);
err1:
--
2.25.1
