Hi Kieran, On Fri, Apr 10, 2020 at 09:20:25AM +0100, Kieran Bingham wrote: > On 09/04/2020 17:33, Laurent Pinchart wrote: > > On Thu, Apr 09, 2020 at 01:11:51PM +0100, Kieran Bingham wrote: > >> v8: > >> - Convert probe kzalloc usage to devm_ variant > > > > This isn't worse than the existing code, but are you aware that devm_* > > should not be used in this case ? The memory should be allocated with > > kzalloc() and freed in the .release() operation. > > This change was at the request of a review comment from Sakari. > > From: > https://lore.kernel.org/linux-media/4139f241-2fde-26ad-fe55-dcaeb76ad6cc@xxxxxxxxxxxxxxxx/ > > >>> + > >>> +static int max9286_probe(struct i2c_client *client) > >>> +{ > >>> + struct max9286_priv *priv; > >>> + unsigned int i; > >>> + int ret; > >>> + > >>> + priv = kzalloc(sizeof(*priv), GFP_KERNEL); > >>> + if (!priv) > >>> + return -ENOMEM; > >> > >> You won't lose anything by using the devm_ variant here. > > > > Indeed, > > > >>> + > >>> + priv->client = client; > >>> + i2c_set_clientdata(client, priv); > >>> + > >>> + for (i = 0; i < MAX9286_N_SINKS; i++) > >>> + max9286_init_format(&priv->fmt[i]); > >>> + > >>> + ret = max9286_parse_dt(priv); > >>> + if (ret) > >>> + return ret; > >> > >> But you can avoid accidental memory leaks for nothing. :-) > > > > It would be good not to leak indeed! > > I understand that there are lifetime issues in V4L2 - but in my opinion > that needs to be handled by core V4l2 (and or support from driver core > framework). I'm afraid that's not possible. The V4L2 core can't delay remove(). There are helpers we could create to simplify correct memory management for drivers, but in any case, devm_kzalloc() isn't correct. There are also issues in the core that would make unbinding unsafe even if correctly implemented in this driver, but a correct implementation in drivers will be required in any case. As I said before this patch isn't a regression as memory allocation is already broken here, but it doesn't go in the right direction either. > Also - isn't it highly unlikely to affect the max9286? Isn't the > lifetime issue that the device can be unplugged while the file handle is > open? > > I don't think anyone is going to 'unplug' the max9286 while it's active :-) No, but someone could unbind it through sysfs. In any case it's not an excuse to not implement memory allocation correctly :-) > >> --- > >> drivers/media/i2c/max9286.c | 5 +---- > >> 1 file changed, 1 insertion(+), 4 deletions(-) > >> > >> diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c > >> index b84d2daa6561..0a43137b8112 100644 > >> --- a/drivers/media/i2c/max9286.c > >> +++ b/drivers/media/i2c/max9286.c > >> @@ -1155,7 +1155,7 @@ static int max9286_probe(struct i2c_client *client) > >> unsigned int i; > >> int ret; > >> > >> - priv = kzalloc(sizeof(*priv), GFP_KERNEL); > >> + priv = devm_kzalloc(&client->dev, sizeof(*priv), GFP_KERNEL); > >> if (!priv) > >> return -ENOMEM; > >> > >> @@ -1232,7 +1232,6 @@ static int max9286_probe(struct i2c_client *client) > >> max9286_configure_i2c(priv, false); > >> err_free: > >> max9286_cleanup_dt(priv); > >> - kfree(priv); > >> > >> return ret; > >> } > >> @@ -1253,8 +1252,6 @@ static int max9286_remove(struct i2c_client *client) > >> > >> gpiod_set_value_cansleep(priv->gpiod_pwdn, 0); > >> > >> - kfree(priv); > >> - > >> return 0; > >> } > >> -- Regards, Laurent Pinchart
