public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Samuel Iglesias Gonsálvez" <siglesias@igalia.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jens Taprogge <jens.taprogge@taprogge.org>,
	industrypack-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ipack: add missing put_device() after device_register() failed
Date: Wed, 27 Feb 2013 10:00:35 +0100	[thread overview]
Message-ID: <512DCB33.6030500@igalia.com> (raw)
In-Reply-To: <20130226222842.GA20670@core.coreip.homeip.net>

Hello Dmitry,

First of all, thanks for your comments.

On 02/26/2013 11:28 PM, Dmitry Torokhov wrote:
> On Tue, Feb 26, 2013 at 10:03:15AM +0100, Samuel Iglesias Gonsalvez wrote:
>> put_device() must be called after device_register() fails,
>> since device_register() always initializes the refcount
>> on the device structure to one.
>>
>> dev->id is free'd inside of ipack_device_release function.
>> So, it's not needed to do it here.
>>
>> Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
>> ---
>>  drivers/ipack/ipack.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
>> index 7ec6b20..3588ccf 100644
>> --- a/drivers/ipack/ipack.c
>> +++ b/drivers/ipack/ipack.c
>> @@ -449,7 +449,7 @@ int ipack_device_register(struct ipack_device *dev)
>>  
>>  	ret = device_register(&dev->dev);
>>  	if (ret < 0)
>> -		kfree(dev->id);
>> +		put_device(&dev->dev);
> 
> Now callers have no idea if they have to free (put_device) it in case of
> failure or it is already done for them, because a few lines earlier, if
> pack_device_read_id() fails, it simply returns error code.
> 
> IMO if a function did not allocate object it should not try to free it,
> callers should dispose of the device as they see fit.
> 
> What is missing, however, is dev->id = NULL assignment so that if caller
> does put_device() kit won't double-free the memory.

OK. I will write a patch.

> Also it would make
> sense to split device_register into device_init() and device_add() so
> that device_init() is very first thing you do and in case of all
> failures callers should use put_device().
> 

It makes sense. I will write a patch for it.

> Also tpci200.c need to learn to clean up after itself and I also not
> sure why it tries to provide its own release function.
>

tpci200 driver is the one who allocated the struct ipack_device and it
should free it. The path to release it is the following:

* The kernel will call the corresponding release() function of the
struct device. This callback is linked to ipack_release_device() in
ipack.c. In that function, there is a kfree(dev->id) as it was
previously allocated by ipack bus driver.

* Then, ipack_release_device() calls the carrier's release function to
indicate that the device is being released and the carrier driver needs
to take care of its own resources.

In summary, each driver allocate and free its own resources when
unregistering a device.

Thanks,

Sam

  reply	other threads:[~2013-02-27  9:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26  9:03 [PATCH] ipack: add missing put_device() after device_register() failed Samuel Iglesias Gonsalvez
2013-02-26 22:28 ` Dmitry Torokhov
2013-02-27  9:00   ` Samuel Iglesias Gonsálvez [this message]
2013-03-08  8:21     ` [PATCH 1/3] ipack: avoid double free on device->id Samuel Iglesias Gonsalvez
2013-03-08  8:21       ` [PATCH 2/3] ipack: add ipack_get_device() ipack_put_device() Samuel Iglesias Gonsalvez
2013-03-08  8:21       ` [PATCH 3/3] ipack: split ipack_device_register() in several functions Samuel Iglesias Gonsalvez
2013-03-08 17:47       ` [PATCH 1/3] ipack: avoid double free on device->id Greg Kroah-Hartman
2013-03-08 18:11         ` Samuel Iglesias Gonsálvez
2013-03-08 18:11         ` Samuel Iglesias Gonsálvez
2013-03-08 19:36           ` Greg Kroah-Hartman
2013-03-11  7:58             ` Samuel Iglesias Gonsálvez

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=512DCB33.6030500@igalia.com \
    --to=siglesias@igalia.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=industrypack-devel@lists.sourceforge.net \
    --cc=jens.taprogge@taprogge.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox