All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-clk <linux-clk@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v1] clk: Convert managed get functions to devm_add_action API
Date: Thu, 12 Dec 2019 14:46:16 +0000	[thread overview]
Message-ID: <20191212144616.GJ25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <58c27422-e06c-f42e-16ea-baeca3bb9b01@free.fr>

On Thu, Dec 12, 2019 at 03:41:20PM +0100, Marc Gonzalez wrote:
> On 12/12/2019 15:17, Russell King - ARM Linux admin wrote:
> 
> > On Thu, Dec 12, 2019 at 02:53:40PM +0100, Marc Gonzalez wrote:
> >
> >> On 11/12/2019 23:28, Dmitry Torokhov wrote:
> >>
> >>> On Wed, Dec 11, 2019 at 05:17:28PM +0100, Marc Gonzalez wrote:
> >>>
> >>>> What is the rationale for the devm_add_action API?
> >>>
> >>> For one-off and maybe complex unwind actions in drivers that wish to use
> >>> devm API (as mixing devm and manual release is verboten). Also is often
> >>> used when some core subsystem does not provide enough devm APIs.
> >>
> >> Thanks for the insight, Dmitry. Thanks to Robin too.
> >>
> >> This is what I understand so far:
> >>
> >> devm_add_action() is nice because it hides/factorizes the complexity
> >> of the devres API, but it incurs a small storage overhead of one
> >> pointer per call, which makes it unfit for frequently used actions,
> >> such as clk_get.
> >>
> >> Is that correct?
> >>
> >> My question is: why not design the API without the small overhead?
> >>
> >> Proof of concept below:
> >>
> >>
> >> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> >> index 0bbb328bd17f..76392dd6273b 100644
> >> --- a/drivers/base/devres.c
> >> +++ b/drivers/base/devres.c
> >> @@ -685,6 +685,20 @@ int devres_release_group(struct device *dev, void *id)
> >>  }
> >>  EXPORT_SYMBOL_GPL(devres_release_group);
> >>  
> >> +void *devm_add(struct device *dev, dr_release_t func, void *arg, size_t size)
> >> +{
> >> +	void *data = devres_alloc(func, size, GFP_KERNEL);
> >> +
> >> +	if (data) {
> >> +		memcpy(data, arg, size);
> >> +		devres_add(dev, data);
> >> +	} else
> >> +		func(dev, arg);
> >> +
> >> +	return data;
> >> +}
> >> +EXPORT_SYMBOL_GPL(devm_add);
> >> +
> >>  /*
> >>   * Custom devres actions allow inserting a simple function call
> >>   * into the teadown sequence.
> >> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> >> index be160764911b..8db671823126 100644
> >> --- a/drivers/clk/clk-devres.c
> >> +++ b/drivers/clk/clk-devres.c
> >> @@ -4,6 +4,11 @@
> >>  #include <linux/export.h>
> >>  #include <linux/gfp.h>
> >>  
> >> +static void __clk_put(struct device *dev, void *data)
> >> +{
> >> +	clk_put(*(struct clk **)data);
> >> +}
> >> +
> >>  static void devm_clk_release(struct device *dev, void *res)
> >>  {
> >>  	clk_put(*(struct clk **)res);
> >> @@ -11,19 +16,11 @@ static void devm_clk_release(struct device *dev, void *res)
> >>  
> >>  struct clk *devm_clk_get(struct device *dev, const char *id)
> >>  {
> >> -	struct clk **ptr, *clk;
> >> -
> >> -	ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
> >> -	if (!ptr)
> >> -		return ERR_PTR(-ENOMEM);
> >> +	struct clk *clk = clk_get(dev, id);
> >>  
> >> -	clk = clk_get(dev, id);
> >> -	if (!IS_ERR(clk)) {
> >> -		*ptr = clk;
> >> -		devres_add(dev, ptr);
> >> -	} else {
> >> -		devres_free(ptr);
> >> -	}
> >> +	if (!IS_ERR(clk))
> >> +		if (!devm_add(dev, __clk_put, &clk, sizeof(clk)))
> >> +			clk = ERR_PTR(-ENOMEM);
> > 
> > You leak clk here.
> 
> I don't think so ;-)
> 
> If devm_add() returns NULL, then we have called __clk_put(dev, &clk);

Okay.

However, please don't call this __clk_put().  git grep __clk_put will
tell you why.  Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v1] clk: Convert managed get functions to devm_add_action API
Date: Thu, 12 Dec 2019 14:46:16 +0000	[thread overview]
Message-ID: <20191212144616.GJ25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <58c27422-e06c-f42e-16ea-baeca3bb9b01@free.fr>

On Thu, Dec 12, 2019 at 03:41:20PM +0100, Marc Gonzalez wrote:
> On 12/12/2019 15:17, Russell King - ARM Linux admin wrote:
> 
> > On Thu, Dec 12, 2019 at 02:53:40PM +0100, Marc Gonzalez wrote:
> >
> >> On 11/12/2019 23:28, Dmitry Torokhov wrote:
> >>
> >>> On Wed, Dec 11, 2019 at 05:17:28PM +0100, Marc Gonzalez wrote:
> >>>
> >>>> What is the rationale for the devm_add_action API?
> >>>
> >>> For one-off and maybe complex unwind actions in drivers that wish to use
> >>> devm API (as mixing devm and manual release is verboten). Also is often
> >>> used when some core subsystem does not provide enough devm APIs.
> >>
> >> Thanks for the insight, Dmitry. Thanks to Robin too.
> >>
> >> This is what I understand so far:
> >>
> >> devm_add_action() is nice because it hides/factorizes the complexity
> >> of the devres API, but it incurs a small storage overhead of one
> >> pointer per call, which makes it unfit for frequently used actions,
> >> such as clk_get.
> >>
> >> Is that correct?
> >>
> >> My question is: why not design the API without the small overhead?
> >>
> >> Proof of concept below:
> >>
> >>
> >> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> >> index 0bbb328bd17f..76392dd6273b 100644
> >> --- a/drivers/base/devres.c
> >> +++ b/drivers/base/devres.c
> >> @@ -685,6 +685,20 @@ int devres_release_group(struct device *dev, void *id)
> >>  }
> >>  EXPORT_SYMBOL_GPL(devres_release_group);
> >>  
> >> +void *devm_add(struct device *dev, dr_release_t func, void *arg, size_t size)
> >> +{
> >> +	void *data = devres_alloc(func, size, GFP_KERNEL);
> >> +
> >> +	if (data) {
> >> +		memcpy(data, arg, size);
> >> +		devres_add(dev, data);
> >> +	} else
> >> +		func(dev, arg);
> >> +
> >> +	return data;
> >> +}
> >> +EXPORT_SYMBOL_GPL(devm_add);
> >> +
> >>  /*
> >>   * Custom devres actions allow inserting a simple function call
> >>   * into the teadown sequence.
> >> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> >> index be160764911b..8db671823126 100644
> >> --- a/drivers/clk/clk-devres.c
> >> +++ b/drivers/clk/clk-devres.c
> >> @@ -4,6 +4,11 @@
> >>  #include <linux/export.h>
> >>  #include <linux/gfp.h>
> >>  
> >> +static void __clk_put(struct device *dev, void *data)
> >> +{
> >> +	clk_put(*(struct clk **)data);
> >> +}
> >> +
> >>  static void devm_clk_release(struct device *dev, void *res)
> >>  {
> >>  	clk_put(*(struct clk **)res);
> >> @@ -11,19 +16,11 @@ static void devm_clk_release(struct device *dev, void *res)
> >>  
> >>  struct clk *devm_clk_get(struct device *dev, const char *id)
> >>  {
> >> -	struct clk **ptr, *clk;
> >> -
> >> -	ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
> >> -	if (!ptr)
> >> -		return ERR_PTR(-ENOMEM);
> >> +	struct clk *clk = clk_get(dev, id);
> >>  
> >> -	clk = clk_get(dev, id);
> >> -	if (!IS_ERR(clk)) {
> >> -		*ptr = clk;
> >> -		devres_add(dev, ptr);
> >> -	} else {
> >> -		devres_free(ptr);
> >> -	}
> >> +	if (!IS_ERR(clk))
> >> +		if (!devm_add(dev, __clk_put, &clk, sizeof(clk)))
> >> +			clk = ERR_PTR(-ENOMEM);
> > 
> > You leak clk here.
> 
> I don't think so ;-)
> 
> If devm_add() returns NULL, then we have called __clk_put(dev, &clk);

Okay.

However, please don't call this __clk_put().  git grep __clk_put will
tell you why.  Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-12-12 14:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 16:13 [PATCH v1] clk: Convert managed get functions to devm_add_action API Marc Gonzalez
2019-11-26 16:13 ` Marc Gonzalez
2019-11-28 18:56 ` Bjorn Andersson
2019-11-28 18:56   ` Bjorn Andersson
2019-12-02  1:42   ` Dmitry Torokhov
2019-12-02  1:42     ` Dmitry Torokhov
2019-12-02  9:25     ` Marc Gonzalez
2019-12-02  9:25       ` Marc Gonzalez
2019-12-02 13:51       ` Robin Murphy
2019-12-02 13:51         ` Robin Murphy
2019-12-11 16:17         ` Marc Gonzalez
2019-12-11 16:17           ` Marc Gonzalez
2019-12-11 22:28           ` Dmitry Torokhov
2019-12-11 22:28             ` Dmitry Torokhov
2019-12-12 13:53             ` Marc Gonzalez
2019-12-12 13:53               ` Marc Gonzalez
2019-12-12 14:17               ` Russell King - ARM Linux admin
2019-12-12 14:17                 ` Russell King - ARM Linux admin
2019-12-12 14:41                 ` Marc Gonzalez
2019-12-12 14:41                   ` Marc Gonzalez
2019-12-12 14:46                   ` Russell King - ARM Linux admin [this message]
2019-12-12 14:46                     ` Russell King - ARM Linux admin
2019-12-12 15:51                     ` Marc Gonzalez
2019-12-12 15:51                       ` Marc Gonzalez
2019-12-12 16:13                       ` Russell King - ARM Linux admin
2019-12-12 16:13                         ` Russell King - ARM Linux admin
2019-12-12 14:47               ` Robin Murphy
2019-12-12 14:47                 ` Robin Murphy
2019-12-12 16:59                 ` Marc Gonzalez
2019-12-12 16:59                   ` Marc Gonzalez
2019-12-12 17:05                   ` Russell King - ARM Linux admin
2019-12-12 17:05                     ` Russell King - ARM Linux admin
2019-12-12 18:15                   ` Robin Murphy
2019-12-12 18:15                     ` Robin Murphy
2019-12-12 19:10                     ` Dmitry Torokhov
2019-12-12 19:10                       ` Dmitry Torokhov
2019-12-12 21:08                       ` Robin Murphy
2019-12-12 21:08                         ` Robin Murphy
2019-12-13  0:16                         ` Dmitry Torokhov
2019-12-13  0:16                           ` Dmitry Torokhov

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=20191212144616.GJ25745@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=bjorn.andersson@linaro.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=marc.w.gonzalez@free.fr \
    --cc=mturquette@baylibre.com \
    --cc=robin.murphy@arm.com \
    --cc=sboyd@kernel.org \
    --cc=sudipm.mukherjee@gmail.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.