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>
---
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
Hi List!
I'm currently using gbridge / tcpip with the
IID1-simple-gpio-module.mnfs example to hook up a fake module that
just responds to socket I/O.
A couple of small changes were required, but everything seems to be
parsed, bundles, cports are all created.
However, for some reason, greybus does not seem to automatically bind
the device to the gb-gpio driver, nor does it probe the device. I only
see pings after the svc has inserted my fake module and handshake is
complete.
Is anyone aware if a separate step that is required to bind the device
to the driver?
I've tried
sudo sh -c 'echo -n 1-2.2.1 > /sys/bus/gbphy/drivers/gpio/bind'
but that gives me -ENODEV
Any pointers would be great!
Thanks,
C
Hi,
I have been working on the Google Summer of Code Project : Click Board
Support through Greybus
<https://summerofcode.withgoogle.com/projects/#5996499987595264> , which
aims to bring in support for MikroElektronika Click Boards
<https://www.mikroe.com/click> through Greybus Simulator
<https://github.com/projectara/gbsim> , I was able to set up and bring in
support for some of the Click boards through Greybus Simulator and passing
the properties related to the Click Board device driver manipulating the
product string and vendor string properties in the manifest, however I am
stuck now as some of the click boards require additional platform data(like
Reset Pin, Interrupts..etc) passed to the spi_new_device/i2c_new_device
calls, does Greybus allow passing of these parameters to the driver, if so
can someone guide me with the documentation for the same or point me a
suitable example so that I can implement the solution in the project.
If greybus doesn't allow for passing these parameters what would be the
ideal way to bring in support for these click boards(which mostly uses
SPI/I2C interfaces) through the greybus subsystem?.
Thanks and Regards
Vaishnav M A
GSoC '19 Student Under Beagleboard.org
