greybus-dev

greybus-dev@lists.linaro.org

6 participants
595 discussions

[PATCH] staging: greybus: Replace zero-length array with flexible-array member

by Gustavo A. R. Silva

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> --- drivers/staging/greybus/raw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c index 838acbe84ca0..2b301b2aa107 100644 --- a/drivers/staging/greybus/raw.c +++ b/drivers/staging/greybus/raw.c @@ -30,7 +30,7 @@ struct gb_raw { struct raw_data { struct list_head entry; u32 len; - u8 data[0]; + u8 data[]; }; static struct class *raw_class; -- 2.25.0

5 years, 8 months

[PATCH] staging: greybus: use after free in gb_audio_manager_remove_all()

by Dan Carpenter

When we call kobject_put() and it's the last reference to the kobject then it calls gb_audio_module_release() and frees module. We dereference "module" on the next line which is a use after free. Fixes: c77f85bbc91a ("greybus: audio: Fix incorrect counting of 'ida'") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/staging/greybus/audio_manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/audio_manager.c b/drivers/staging/greybus/audio_manager.c index 9b19ea9d3fa1..9a3f7c034ab4 100644 --- a/drivers/staging/greybus/audio_manager.c +++ b/drivers/staging/greybus/audio_manager.c @@ -92,8 +92,8 @@ void gb_audio_manager_remove_all(void) list_for_each_entry_safe(module, next, &modules_list, list) { list_del(&module->list); - kobject_put(&module->kobj); ida_simple_remove(&module_id, module->id); + kobject_put(&module->kobj); } is_empty = list_empty(&modules_list); -- 2.11.0

5 years, 8 months

[PATCH] staging: greybus: bootrom: fix uninitialized variables

by Saurav Girepunje

fix uninitialized variables issue found using static code analysis tool (error) Uninitialized variable: offset (error) Uninitialized variable: size Signed-off-by: Saurav Girepunje <saurav.girepunje(a)gmail.com> --- drivers/staging/greybus/bootrom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index a8efb86..9eabeb3 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -245,7 +245,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) struct gb_bootrom_get_firmware_request *firmware_request; struct gb_bootrom_get_firmware_response *firmware_response; struct device *dev = &op->connection->bundle->dev; - unsigned int offset, size; + unsigned int offset = 0, size = 0; enum next_request_type next_request; int ret = 0; -- 1.9.1

5 years, 9 months

[PATCH] staging: greybus: fix fw is NULL but dereferenced.

by Saurav Girepunje

Fix the warning reported by cocci check. Changes: In queue_work fw dereference before it actually get assigned. move queue_work before gb_bootrom_set_timeout. As gb_bootrom_get_firmware () return NEXT_REQ_READY_TO_BOOT only when there is no error and offset + size is actually equal to fw->size. So initialized next_request to NEXT_REQ_GET_FIRMWARE for return in other case. Signed-off-by: Saurav Girepunje <saurav.girepunje(a)gmail.com> --- drivers/staging/greybus/bootrom.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index a8efb86..f54514e 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -246,7 +246,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) struct gb_bootrom_get_firmware_response *firmware_response; struct device *dev = &op->connection->bundle->dev; unsigned int offset, size; - enum next_request_type next_request; + enum next_request_type next_request = NEXT_REQ_GET_FIRMWARE; int ret = 0; /* Disable timeouts */ @@ -296,13 +296,11 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) unlock: mutex_unlock(&bootrom->mutex); -queue_work: /* Refresh timeout */ if (!ret && (offset + size == fw->size)) next_request = NEXT_REQ_READY_TO_BOOT; - else - next_request = NEXT_REQ_GET_FIRMWARE; +queue_work: gb_bootrom_set_timeout(bootrom, next_request, NEXT_REQ_TIMEOUT_MS); return ret; -- 1.9.1

5 years, 9 months

[PATCH AUTOSEL 4.9 193/251] staging: greybus: light: fix a couple double frees

by Sasha Levin

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 329101244f214952606359d254ae883b7109e1a5 ] The problem is in gb_lights_request_handler(). If we get a request to change the config then we release the light with gb_lights_light_release() and re-allocated it. However, if the allocation fails part way through then we call gb_lights_light_release() again. This can lead to a couple different double frees where we haven't cleared out the original values: gb_lights_light_v4l2_unregister(light); ... kfree(light->channels); kfree(light->name); I also made a small change to how we set "light->channels_count = 0;". The original code handled this part fine and did not cause a use after free but it was sort of complicated to read. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20190829122839.GA20116@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/light.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 9f01427f35f9..1cb82cc28aa7 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1102,21 +1102,21 @@ static void gb_lights_channel_release(struct gb_channel *channel) static void gb_lights_light_release(struct gb_light *light) { int i; - int count; light->ready = false; - count = light->channels_count; - if (light->has_flash) gb_lights_light_v4l2_unregister(light); + light->has_flash = false; - for (i = 0; i < count; i++) { + for (i = 0; i < light->channels_count; i++) gb_lights_channel_release(&light->channels[i]); - light->channels_count--; - } + light->channels_count = 0; + kfree(light->channels); + light->channels = NULL; kfree(light->name); + light->name = NULL; } static void gb_lights_release(struct gb_lights *glights) -- 2.20.1

5 years, 9 months

[PATCH AUTOSEL 4.14 283/371] staging: greybus: light: fix a couple double frees

by Sasha Levin

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 329101244f214952606359d254ae883b7109e1a5 ] The problem is in gb_lights_request_handler(). If we get a request to change the config then we release the light with gb_lights_light_release() and re-allocated it. However, if the allocation fails part way through then we call gb_lights_light_release() again. This can lead to a couple different double frees where we haven't cleared out the original values: gb_lights_light_v4l2_unregister(light); ... kfree(light->channels); kfree(light->name); I also made a small change to how we set "light->channels_count = 0;". The original code handled this part fine and did not cause a use after free but it was sort of complicated to read. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20190829122839.GA20116@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/light.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 0f538b8c3a07..4e7575147775 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1103,21 +1103,21 @@ static void gb_lights_channel_release(struct gb_channel *channel) static void gb_lights_light_release(struct gb_light *light) { int i; - int count; light->ready = false; - count = light->channels_count; - if (light->has_flash) gb_lights_light_v4l2_unregister(light); + light->has_flash = false; - for (i = 0; i < count; i++) { + for (i = 0; i < light->channels_count; i++) gb_lights_channel_release(&light->channels[i]); - light->channels_count--; - } + light->channels_count = 0; + kfree(light->channels); + light->channels = NULL; kfree(light->name); + light->name = NULL; } static void gb_lights_release(struct gb_lights *glights) -- 2.20.1

5 years, 9 months

[PATCH AUTOSEL 4.19 518/671] staging: greybus: light: fix a couple double frees

by Sasha Levin

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 329101244f214952606359d254ae883b7109e1a5 ] The problem is in gb_lights_request_handler(). If we get a request to change the config then we release the light with gb_lights_light_release() and re-allocated it. However, if the allocation fails part way through then we call gb_lights_light_release() again. This can lead to a couple different double frees where we haven't cleared out the original values: gb_lights_light_v4l2_unregister(light); ... kfree(light->channels); kfree(light->name); I also made a small change to how we set "light->channels_count = 0;". The original code handled this part fine and did not cause a use after free but it was sort of complicated to read. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20190829122839.GA20116@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/greybus/light.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 010ae1e9c7fb..40680eaf3974 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1098,21 +1098,21 @@ static void gb_lights_channel_release(struct gb_channel *channel) static void gb_lights_light_release(struct gb_light *light) { int i; - int count; light->ready = false; - count = light->channels_count; - if (light->has_flash) gb_lights_light_v4l2_unregister(light); + light->has_flash = false; - for (i = 0; i < count; i++) { + for (i = 0; i < light->channels_count; i++) gb_lights_channel_release(&light->channels[i]); - light->channels_count--; - } + light->channels_count = 0; + kfree(light->channels); + light->channels = NULL; kfree(light->name); + light->name = NULL; } static void gb_lights_release(struct gb_lights *glights) -- 2.20.1

5 years, 9 months

Potential memory leak in greybus/svc.c

by Navid Emamdoost

Hello, It seems to me there is a memory leak in the implementation of gb_svc_create(). In the error handling path (labeled as err_put_device) the code correctly puts svc->dev, but I am suspicious that svc->wq is leaking. The allocated svc->wq needs a release via destroy_workqueue() in the error handling path. Am I missing something? Thank you, -- Navid.

5 years, 10 months

[PATCH] staging: greybus: add blank line after declarations

by Gabriela Bittencourt

Fix CHECK: add blank line after declarations Signed-off-by: Gabriela Bittencourt <gabrielabittencourt00(a)gmail.com> --- drivers/staging/greybus/control.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/greybus/control.h b/drivers/staging/greybus/control.h index 3a29ec05f631..5a45d55349a1 100644 --- a/drivers/staging/greybus/control.h +++ b/drivers/staging/greybus/control.h @@ -24,6 +24,7 @@ struct gb_control { char *vendor_string; char *product_string; }; + #define to_gb_control(d) container_of(d, struct gb_control, dev) struct gb_control *gb_control_create(struct gb_interface *intf); -- 2.20.1

6 years

[PATCH] greybus: remove excessive check in gb_connection_hd_cport_quiesce()

by Denis Efremov

Function pointer "hd->driver->cport_quiesce" is already checked at the beginning of gb_connection_hd_cport_quiesce(). Thus, the second check can be removed. Signed-off-by: Denis Efremov <efremov(a)linux.com> --- drivers/greybus/connection.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/greybus/connection.c b/drivers/greybus/connection.c index fc8f57f97ce6..e3799a53a193 100644 --- a/drivers/greybus/connection.c +++ b/drivers/greybus/connection.c @@ -361,9 +361,6 @@ static int gb_connection_hd_cport_quiesce(struct gb_connection *connection) if (connection->mode_switch) peer_space += sizeof(struct gb_operation_msg_hdr); - if (!hd->driver->cport_quiesce) - return 0; - ret = hd->driver->cport_quiesce(hd, connection->hd_cport_id, peer_space, GB_CONNECTION_CPORT_QUIESCE_TIMEOUT); -- 2.21.0

6 years, 1 month

← Newer
1
...
39
40
41
42
43
44
45
...
60
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev