From: Peter Wu <lekensteyn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Martin Mokrejs
<mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>,
Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: How should dev_[gs]et_drvdata be used?
Date: Tue, 24 Dec 2013 01:18:03 +0100 [thread overview]
Message-ID: <1716344.EUMSGCAAKK@al> (raw)
In-Reply-To: <1387820241.30327.105.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
On Monday 23 December 2013 10:37:21 Alex Williamson wrote:
> On Mon, 2013-12-23 at 16:49 +0100, Peter Wu wrote:
[..]
> >
> > There is still one thing I do not fully understand, how should
> > dev_set_drvdata and dev_get_drvdata be used? For the devices passed
> > to probe functions, the core takes care of setting to NULL on error.
> > Then device_unregister frees the memory, right?
> >
> > Now, what if the dev_set_drvdata (or aliases such as pci_set_drvdata,
> > i2c_set_adapinfo, etc.) are manually called outside probe functions?
> > Or inside the probe function, but not for the device that is being
> > probed (such as is the case with the i801 i2c driver)?
> >
> > The VFIO driver also does something odd, it clears the driver data,
> > but the device holding it is freed using kfree():
> >
> > static void vfio_device_release(struct kref *kref) {
> > struct vfio_device *device = container_of(kref,
> > struct vfio_device, kref);
> > struct vfio_group *group = device->group;
> >
> > list_del(&device->group_next);
> > mutex_unlock(&group->device_lock);
> >
> > dev_set_drvdata(device->dev, NULL);
> >
> > kfree(device);
> >
> > Is a memory leak also present here since dev_set_drvdata() always tries to
> > allocate memory?
>
> But it doesn't:
>
> int dev_set_drvdata(struct device *dev, void *data)
> {
> int error;
>
> if (!dev->p) {
> error = device_private_init(dev);
> if (error)
> return error;
> }
> dev->p->driver_data = data;
> return 0;
> }
It does:
int device_private_init(struct device *dev)
{
dev->p = kzalloc(sizeof(*dev->p), GFP_KERNEL);
if (!dev->p)
return -ENOMEM;
dev->p->device = dev;
klist_init(&dev->p->klist_children, klist_children_get,
klist_children_put);
INIT_LIST_HEAD(&dev->p->deferred_probe);
return 0;
}
and if it doesn't, then I must be missing something in this non-obvious
code. I scanned the interwebs and Documentation/, but could not really
find a great example on how this is supposed to work. The dev_set_drvdata
function existed since Linus moved to git.
> Also, the code referenced is kfree'ing a struct vfio_device, not the
> struct device. VFIO uses the drvdata to provide a back pointer to the
> vfio specific structure, which also includes a pointer to the struct
> device. We obviously want to clear drvdata when the vfio specific
> structure is being released.
Ah, I see. "device->dev" is not freed, but "device". And the data is
cleared for "device->dev". Thanks for correcting.
Clear examples of how to use dev_{s,g}et_drvdata correctly in i2c is
still wanted. I stepped in it yesterday, i2c seems to have its own
way to register new devices. More specifically, how can the memory
associated with dev_set_drvdata be free'd on error paths if the
device is not registered with device_register (as is done in the
probe function of the i801 i2c driver)?
Regards,
Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Wu <lekensteyn@gmail.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>,
Jean Delvare <khali@linux-fr.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: How should dev_[gs]et_drvdata be used?
Date: Tue, 24 Dec 2013 01:18:03 +0100 [thread overview]
Message-ID: <1716344.EUMSGCAAKK@al> (raw)
In-Reply-To: <1387820241.30327.105.camel@bling.home>
On Monday 23 December 2013 10:37:21 Alex Williamson wrote:
> On Mon, 2013-12-23 at 16:49 +0100, Peter Wu wrote:
[..]
> >
> > There is still one thing I do not fully understand, how should
> > dev_set_drvdata and dev_get_drvdata be used? For the devices passed
> > to probe functions, the core takes care of setting to NULL on error.
> > Then device_unregister frees the memory, right?
> >
> > Now, what if the dev_set_drvdata (or aliases such as pci_set_drvdata,
> > i2c_set_adapinfo, etc.) are manually called outside probe functions?
> > Or inside the probe function, but not for the device that is being
> > probed (such as is the case with the i801 i2c driver)?
> >
> > The VFIO driver also does something odd, it clears the driver data,
> > but the device holding it is freed using kfree():
> >
> > static void vfio_device_release(struct kref *kref) {
> > struct vfio_device *device = container_of(kref,
> > struct vfio_device, kref);
> > struct vfio_group *group = device->group;
> >
> > list_del(&device->group_next);
> > mutex_unlock(&group->device_lock);
> >
> > dev_set_drvdata(device->dev, NULL);
> >
> > kfree(device);
> >
> > Is a memory leak also present here since dev_set_drvdata() always tries to
> > allocate memory?
>
> But it doesn't:
>
> int dev_set_drvdata(struct device *dev, void *data)
> {
> int error;
>
> if (!dev->p) {
> error = device_private_init(dev);
> if (error)
> return error;
> }
> dev->p->driver_data = data;
> return 0;
> }
It does:
int device_private_init(struct device *dev)
{
dev->p = kzalloc(sizeof(*dev->p), GFP_KERNEL);
if (!dev->p)
return -ENOMEM;
dev->p->device = dev;
klist_init(&dev->p->klist_children, klist_children_get,
klist_children_put);
INIT_LIST_HEAD(&dev->p->deferred_probe);
return 0;
}
and if it doesn't, then I must be missing something in this non-obvious
code. I scanned the interwebs and Documentation/, but could not really
find a great example on how this is supposed to work. The dev_set_drvdata
function existed since Linus moved to git.
> Also, the code referenced is kfree'ing a struct vfio_device, not the
> struct device. VFIO uses the drvdata to provide a back pointer to the
> vfio specific structure, which also includes a pointer to the struct
> device. We obviously want to clear drvdata when the vfio specific
> structure is being released.
Ah, I see. "device->dev" is not freed, but "device". And the data is
cleared for "device->dev". Thanks for correcting.
Clear examples of how to use dev_{s,g}et_drvdata correctly in i2c is
still wanted. I stepped in it yesterday, i2c seems to have its own
way to register new devices. More specifically, how can the memory
associated with dev_set_drvdata be free'd on error paths if the
device is not registered with device_register (as is done in the
probe function of the i801 i2c driver)?
Regards,
Peter
next prev parent reply other threads:[~2013-12-24 0:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 11:15 linux-3.7.[1,4]: kmemleak in i801_probe Martin Mokrejs
[not found] ` <50FFC659.1090402-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
2013-01-23 16:42 ` Jean Delvare
2013-01-23 16:42 ` Jean Delvare
[not found] ` <20130123174204.00463f98-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2013-01-23 17:35 ` Martin Mokrejs
2013-01-23 17:35 ` Martin Mokrejs
2013-12-23 9:39 ` [PATCH] i2c: i801: fix memleak on probe error Peter Wu
2013-12-23 9:39 ` Peter Wu
[not found] ` <1387791578-1372-1-git-send-email-lekensteyn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-12-23 10:43 ` Peter Wu
2013-12-23 10:43 ` Peter Wu
2013-12-23 10:51 ` Martin Mokrejs
2013-12-23 10:51 ` Martin Mokrejs
[not found] ` <52B815A0.1060609-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
2013-12-23 15:49 ` How should dev_[gs]et_drvdata be used? (was: Re: [PATCH] i2c: i801: fix memleak on probe error) Peter Wu
2013-12-23 15:49 ` Peter Wu
2013-12-23 17:37 ` Alex Williamson
2013-12-23 17:37 ` Alex Williamson
[not found] ` <1387820241.30327.105.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-12-24 0:18 ` Peter Wu [this message]
2013-12-24 0:18 ` How should dev_[gs]et_drvdata be used? Peter Wu
2013-12-24 1:51 ` Alex Williamson
2013-12-24 1:51 ` Alex Williamson
[not found] ` <1387849869.30327.201.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-12-24 9:44 ` Peter Wu
2013-12-24 9:44 ` Peter Wu
2014-01-08 13:28 ` Jean Delvare
[not found] ` <20140108142849.3993341c-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2014-11-25 21:14 ` Uwe Kleine-König
2014-11-25 21:14 ` Uwe Kleine-König
[not found] ` <20141125211432.GA6008-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-11-28 13:48 ` Jean Delvare
2014-11-28 13:48 ` Jean Delvare
[not found] ` <20141128144813.3e6fd8d9-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2014-11-28 14:04 ` Uwe Kleine-König
2014-11-28 14:04 ` Uwe Kleine-König
2014-01-08 9:05 ` [PATCH] i2c: i801: fix memleak on probe error Jean Delvare
2014-01-08 9:05 ` Jean Delvare
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=1716344.EUMSGCAAKK@al \
--to=lekensteyn-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.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 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.