On Fri, Jun 1, 2018 at 1:57 AM, Bastian Germann
<bastiangerm...@fishpost.de> wrote:
> Use devm_* variants of kstrdup and kzalloc. Get rid of the kfree cleanups.

>  static int atk_debugfs_ggrp_open(struct inode *inode, struct file *file)
>  {
>         struct atk_data *data = inode->i_private;
> +       struct device *dev = &data->acpi_dev->dev;
>         char *buf = NULL;
>         union acpi_object *ret;
>         u8 cls;
> @@ -748,7 +748,7 @@ static int atk_debugfs_ggrp_open(struct inode *inode, 
> struct file *file)
>                 id = &pack->package.elements[0];
>                 if (id->integer.value == data->debugfs.id) {
>                         /* Print the package */
> -                       buf = kzalloc(512, GFP_KERNEL);
> +                       buf = devm_kzalloc(dev, 512, GFP_KERNEL);
>                         if (!buf) {
>                                 ACPI_FREE(ret);
>                                 return -ENOMEM;

Looking to the function name, it feels like you are creating a memory
leak and devm_ is inappropriate here.

> @@ -776,16 +776,9 @@ static ssize_t atk_debugfs_ggrp_read(struct file *file, 
> char __user *buf,
>         return simple_read_from_buffer(buf, count, pos, str, len);
>  }
>
> -static int atk_debugfs_ggrp_release(struct inode *inode, struct file *file)
> -{
> -       kfree(file->private_data);
> -       return 0;
> -}
> -
>  static const struct file_operations atk_debugfs_ggrp_fops = {
>         .read           = atk_debugfs_ggrp_read,
>         .open           = atk_debugfs_ggrp_open,
> -       .release        = atk_debugfs_ggrp_release,
>         .llseek         = no_llseek,
>  };

So do these.

Also the question of time to leave of the objects used for debugfs
communication. Please double check that it's not affected by the
change.

Otherwise looks good.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to