From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Peter Wu <lekensteyn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Mokrejs
<mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] i2c: i801: fix memleak on probe error
Date: Wed, 8 Jan 2014 10:05:41 +0100 [thread overview]
Message-ID: <20140108100541.2ef7ebb7@endymion.delvare> (raw)
In-Reply-To: <4657870.yOE66qJqIC@al>
Hi Peter,
Joining the discussion late as I was on vacation...
On Mon, 23 Dec 2013 11:43:21 +0100, Peter Wu wrote:
> Nevermind this patch, it does not really fix the memleak because
> i2c_set_adapdata() calls dev_set_drvdata() which allocates memory.
> (I must have ran kmemleak too early, right after boot it did not
> give any warnings, now it does).
I can confirm that your proposed patch doesn't fix anything. It makes
no difference if pci_set_drvdata(dev, priv) is called earlier or later.
> RFC: what about dropping i2c_set_adapdata() from the probe function
> and replacing i2c_get_adapdata(adapter) by
> pci_get_drvdata(adapter->pci_dev) on top of this patch? I am not
> sure what the purpose is for i2c_set_adapdata, hence this question.
The purpose of i2c_set_adapdata is to attach a data structure to a
specific i2c_adapter device. In the case of the i2c-i801 driver,
there's only one such (class) device per PCI device so we could indeed
reuse the PCI device data pointer as you suggest above. But in the
general case there can be several i2c_adapter devices and each needs
its own data.
Also for performance reasons we don't want to do that because
pci_get_drvdata(adapter->pci_dev) is slower than
i2c_get_adapdata(adapter) (due to the extra pointer deference.) As this
happens repeatedly at run-time (in function i801_access) we want it to
be as fast as possible.
Note that we could (ab)use i2c_adapter.algo_data to store the
i2c_adapter device-specific data. Some drivers are doing exactly that,
for example i2c-nforce2. I suspect this legacy field is now somewhat
redundant with i2c_set_adapdata() as I couldn't find any i2c bus
driver using both.
--
Jean Delvare
prev parent reply other threads:[~2014-01-08 9:05 UTC|newest]
Thread overview: 16+ 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
[not found] ` <20130123174204.00463f98-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2013-01-23 17:35 ` Martin Mokrejs
2013-12-23 9:39 ` [PATCH] i2c: i801: fix memleak on probe error 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: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 17:37 ` Alex Williamson
[not found] ` <1387820241.30327.105.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-12-24 0:18 ` How should dev_[gs]et_drvdata be used? Peter Wu
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
2014-01-08 13:28 ` Jean Delvare
[not found] ` <20140108142849.3993341c-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
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
[not found] ` <20141128144813.3e6fd8d9-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2014-11-28 14:04 ` Uwe Kleine-König
2014-01-08 9:05 ` Jean Delvare [this message]
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=20140108100541.2ef7ebb7@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=lekensteyn-Re5JQEeQqe8AvxtiuMwx3w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).