public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Jean Delvare <jdelvare@suse.de>
Cc: Peter Wu <lekensteyn@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.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@endymion.delvare>

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@linux-fr.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/  |

  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
2013-01-23 16:42 ` Jean Delvare
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 10:43     ` Peter Wu
2013-12-23 10:51       ` Martin Mokrejs
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
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  9:44                 ` Peter Wu
2014-01-08 13:28               ` Jean Delvare
2014-11-25 21:14                 ` Uwe Kleine-König
2014-11-28 13:48                   ` Jean Delvare
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@pengutronix.de \
    --cc=alex.williamson@redhat.com \
    --cc=jdelvare@suse.de \
    --cc=lekensteyn@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmokrejs@fold.natur.cuni.cz \
    /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