All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Miaoqian Lin <linmq006@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coresight: syscfg: Fix memleak on registration failure in cscfg_create_device
Date: Thu, 20 Jan 2022 11:28:22 -0700	[thread overview]
Message-ID: <20220120182822.GA1342128@p14s> (raw)
In-Reply-To: <20220120175642.GB1338735@p14s>

On Thu, Jan 20, 2022 at 10:56:42AM -0700, Mathieu Poirier wrote:
> Good morning,
> 
> On Mon, Jan 10, 2022 at 07:31:00AM +0000, Miaoqian Lin wrote:
> > device_register() calls device_initialize(),
> > according to doc of device_initialize:
> > 
> >     Use put_device() to give up your reference instead of freeing
> >     * @dev directly once you have called this function.
> 
> That is _if_ device_initialize() is called manually.  In this instance
> @dev is registered with device_register() and unregistered with
> device_unregister().  The latter conforms to the comment you pointed out and
> calls put_device() as expected.

I originally misunderstood the context - you are referring to the failure path in
cscfg_create_device().  You are correct about needing to call put_device() but
your solution will not work when the module is unloaded properly and
device_unregister() is called by way of cscfg_clear_device().  In that case
device_unregister() is already calling put_device().

Here simply calling put_device() instead of cscfg_dev_release() in the error
path should do just fine.  That will call cscfg_dev_release() and the memory
allocated for cscfg_mgr will be release.

> 
> Thanks,
> Mathieu
> 
> > 
> > To prevent potential memleak, use put_device() instead call kfree
> > directly.
> > 
> > Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
> > ---
> >  drivers/hwtracing/coresight/coresight-syscfg.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> > index 43054568430f..007fa1c761a7 100644
> > --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> > @@ -764,7 +764,7 @@ struct device *cscfg_device(void)
> >  /* Must have a release function or the kernel will complain on module unload */
> >  static void cscfg_dev_release(struct device *dev)
> >  {
> > -	kfree(cscfg_mgr);
> > +	put_device(dev);
> >  	cscfg_mgr = NULL;
> >  }
> >  
> > -- 
> > 2.17.1
> > 

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Miaoqian Lin <linmq006@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coresight: syscfg: Fix memleak on registration failure in cscfg_create_device
Date: Thu, 20 Jan 2022 11:28:22 -0700	[thread overview]
Message-ID: <20220120182822.GA1342128@p14s> (raw)
In-Reply-To: <20220120175642.GB1338735@p14s>

On Thu, Jan 20, 2022 at 10:56:42AM -0700, Mathieu Poirier wrote:
> Good morning,
> 
> On Mon, Jan 10, 2022 at 07:31:00AM +0000, Miaoqian Lin wrote:
> > device_register() calls device_initialize(),
> > according to doc of device_initialize:
> > 
> >     Use put_device() to give up your reference instead of freeing
> >     * @dev directly once you have called this function.
> 
> That is _if_ device_initialize() is called manually.  In this instance
> @dev is registered with device_register() and unregistered with
> device_unregister().  The latter conforms to the comment you pointed out and
> calls put_device() as expected.

I originally misunderstood the context - you are referring to the failure path in
cscfg_create_device().  You are correct about needing to call put_device() but
your solution will not work when the module is unloaded properly and
device_unregister() is called by way of cscfg_clear_device().  In that case
device_unregister() is already calling put_device().

Here simply calling put_device() instead of cscfg_dev_release() in the error
path should do just fine.  That will call cscfg_dev_release() and the memory
allocated for cscfg_mgr will be release.

> 
> Thanks,
> Mathieu
> 
> > 
> > To prevent potential memleak, use put_device() instead call kfree
> > directly.
> > 
> > Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
> > ---
> >  drivers/hwtracing/coresight/coresight-syscfg.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> > index 43054568430f..007fa1c761a7 100644
> > --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> > @@ -764,7 +764,7 @@ struct device *cscfg_device(void)
> >  /* Must have a release function or the kernel will complain on module unload */
> >  static void cscfg_dev_release(struct device *dev)
> >  {
> > -	kfree(cscfg_mgr);
> > +	put_device(dev);
> >  	cscfg_mgr = NULL;
> >  }
> >  
> > -- 
> > 2.17.1
> > 

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

  reply	other threads:[~2022-01-20 18:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10  7:31 [PATCH] coresight: syscfg: Fix memleak on registration failure in cscfg_create_device Miaoqian Lin
2022-01-10  7:31 ` Miaoqian Lin
2022-01-20 17:56 ` Mathieu Poirier
2022-01-20 17:56   ` Mathieu Poirier
2022-01-20 18:28   ` Mathieu Poirier [this message]
2022-01-20 18:28     ` Mathieu Poirier
2022-01-24 12:41     ` [PATCH v2] " Miaoqian Lin
2022-01-24 12:41       ` Miaoqian Lin
2022-02-01 17:13       ` Mathieu Poirier
2022-02-01 17:13         ` Mathieu Poirier

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=20220120182822.GA1342128@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linmq006@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=suzuki.poulose@arm.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.