linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>
Cc: Peter Wu <lekensteyn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Alex Williamson
	<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Martin Mokrejs
	<mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@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: Fri, 28 Nov 2014 15:04:01 +0100	[thread overview]
Message-ID: <20141128140401.GD4431@pengutronix.de> (raw)
In-Reply-To: <20141128144813.3e6fd8d9-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>

Hi Jean,

On Fri, Nov 28, 2014 at 02:48:13PM +0100, Jean Delvare wrote:
> On Tue, 25 Nov 2014 22:14:32 +0100, Uwe Kleine-König wrote:
> > On Wed, Jan 08, 2014 at 02:28:49PM +0100, Jean Delvare wrote:
> > > Having looked at the code in deeper detail, I think I understand what
> > > is going on. The problem is with:
> > > 
> > > 	i2c_set_adapdata(&priv->adapter, priv);
> > > 
> > > at the beginning of i801_probe(). It triggers the allocation of dev->p
> > > by the driver core. If we bail out at any point before i2c_add_adapter
> > > (and subsequently device_register) is called, then that memory is never
> > > freed.
> > > 
> > > Unfortunately it is not possible to move the i2c_set_adapdata() call
> > > after i2c_add_adapter(), because the data pointer is needed by code
> > > which runs as part of i2c_add_adapter().
> > > 
> > > We could move it right before the call to i2c_add_adapter(), to make
> > > the problem window smaller, but this wouldn't solve the problem
> > > completely, as i2c_add_adapter() itself can fail before
> > > device_register() is called.
> > > 
> > > The only solution I can think of at this point is to stop using
> > > i2c_set_adapdata() altogether, and use i2c_adapter.algo_data instead:
> > > 
> > > From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
> > > Subject: i2c-i801: Use i2c_adapter.algo_data
> > > 
> > > Use i2c_adapter.algo_data instead of i2c_set/get_adapdata(). The
> > > latter makes use of the driver core's private data mechanism, which
> > > allocates memory. That memory is never released if an error happens
> > > between the call to i2c_set_adapdata() and the actual i2c_adapter
> > > registration.
> >
> > Since commit 1bb6c08abfb6 (which makes the driver core use a pointer in
> > struct device again for dev_set_drvdata; went into v3.16-rc1) this patch
> > is obsolete, right?
> 
> Correct. It was never applied upstream anyway, which is good as I never
> liked it.
I came back to it as it was still in the linux-i2c patchwork queue.
It is set to be superseeded now.

> > (Still there might be the opportunity for a few patches converting all
> > driver to i2c_set_adapdata and then drop adapter.algo_data.)
> 
> That's at least 35 bus drivers that would have to be converted then.
> But you should first check if it is possible to get rid of
> i2c_adapter.algo_data without breaking i2c-algo-bit and i2c-mux. If not
> then converting the bus drivers would really only be a minor cleanup
> with no real benefit (not saying it's not worth it though.)
Yeah. I'm not sure I will address this cleanup, but will keep your hint
on my radar.

Best regards and thanks for your reply,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  parent reply	other threads:[~2014-11-28 14:04 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 [this message]
2014-01-08  9:05             ` [PATCH] i2c: i801: fix memleak on probe error 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=20141128140401.GD4431@pengutronix.de \
    --to=u.kleine-koenig-bicnvbalz9megne8c9+irq@public.gmane.org \
    --cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=jdelvare-l3A5Bk7waGM@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).