All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Zeng Heng <zengheng4@huawei.com>
Cc: brgl@bgdev.pl, linux@roeck-us.net, linus.walleij@linaro.org,
	warthog618@gmail.com, linux-gpio@vger.kernel.org,
	liwei391@huawei.com
Subject: Re: [PATCH v4] gpiolib: fix memory leak in gpiochip_setup_dev()
Date: Fri, 18 Nov 2022 12:28:29 +0200	[thread overview]
Message-ID: <Y3deTZkdGtWLhtIG@smile.fi.intel.com> (raw)
In-Reply-To: <20221118022236.871576-1-zengheng4@huawei.com>

On Fri, Nov 18, 2022 at 10:22:36AM +0800, Zeng Heng wrote:
> Here is a backtrace report about memory leak detected in
> gpiochip_setup_dev():
> 
> unreferenced object 0xffff88810b406400 (size 512):
>   comm "python3", pid 1682, jiffies 4295346908 (age 24.090s)
>   backtrace:
>     kmalloc_trace
>     device_add 		device_private_init at drivers/base/core.c:3361

You missed my comment here about extra space.

> 			(inlined by) device_add at drivers/base/core.c:3411
>     cdev_device_add
>     gpiolib_cdev_register
>     gpiochip_setup_dev
>     gpiochip_add_data_with_key
> 
> gcdev_register() & gcdev_unregister() would call device_add() &
> device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to
> register/unregister device.
> 
> However, if device_add() succeeds, some resource (like
> struct device_private allocated by device_private_init())
> is not released by device_del().
> 
> Therefore, after device_add() succeeds by gcdev_register(), it
> needs to call put_device() to release resource in the error handle
> path.
> 
> Here we move forward the register of release function, and let it
> release every piece of resource by put_device() instead of kfree().

...

> +static void gpiochip_print_register_fail(struct gpio_chip *gc,
> +					 struct gpio_device *gdev,
> +					 const char *func, int ret)
> +{
> +	/* failures here can mean systems won't boot... */
> +	if (ret != -EPROBE_DEFER) {

Wouldn't the following work better?

	if (ret == -EPROBE_DEFER)
		return;

	/* failures here can mean systems won't boot... */
	pr_err(...);

> +		pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", func,
> +			gdev->base, gdev->base + gdev->ngpio - 1,
> +			gc->label ? : "generic", ret);
> +	}
> +}

...

>  err_free_gpiochip_mask:
>  	gpiochip_remove_pin_ranges(gc);
>  	gpiochip_free_valid_mask(gc);
> +	if (gdev->dev.release) {

> +		/* release() has been registered by gpiochip_setup_dev() */

This comment is most probably in a wrong line and should be one line below.

> +		gpiochip_print_register_fail(gc, gdev, __func__, ret);
> +		put_device(&gdev->dev);
> +		return ret;
> +	}

...

>  err_free_gdev:
> -	/* failures here can mean systems won't boot... */
> -	if (ret != -EPROBE_DEFER) {
> -		pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__,
> -		       gdev->base, gdev->base + gdev->ngpio - 1,
> -		       gc->label ? : "generic", ret);
> -	}
> +	gpiochip_print_register_fail(gc, gdev, __func__, ret);
>  	kfree(gdev);
>  	return ret;

Now it looks cleaner, but why you can't use the same return point with the
message? What you need is to neep the range on the stack (which is almost there).

...

Okay, let's leave this for a while, I will think how it can be improved and then
I come up with particular suggestions.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-11-18 10:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 11:53 [PATCH] gpiolib: fix memory leak in gpiochip_setup_dev Zeng Heng
2022-11-08 16:57 ` Kent Gibson
2022-11-09  5:12   ` Kent Gibson
2022-11-09  8:27     ` Zeng Heng
2022-11-09  9:06       ` Kent Gibson
2022-11-09  9:31         ` [PATCH v2] " Zeng Heng
2022-11-09 14:47           ` Andy Shevchenko
2022-11-10  1:26             ` Kent Gibson
2022-11-10  2:36               ` Zeng Heng
2022-11-17  9:02                 ` [PATCH v3] gpiolib: fix memory leak in gpiochip_setup_dev() Zeng Heng
2022-11-17 10:49                   ` Andy Shevchenko
2022-11-17 14:12                     ` Zeng Heng
2022-11-17 15:31                       ` Andy Shevchenko
2022-11-18  2:22                         ` [PATCH v4] " Zeng Heng
2022-11-18 10:28                           ` Andy Shevchenko [this message]
2022-11-18  2:31                         ` [PATCH v3] " Zeng Heng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3deTZkdGtWLhtIG@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=liwei391@huawei.com \
    --cc=warthog618@gmail.com \
    --cc=zengheng4@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.