From: Jean Delvare <khali@linux-fr.org>
To: sensors@Stimpy.netroedge.com, linux-kernel@vger.kernel.org
Cc: greg@kroah.com, vsu@altlinux.ru, sensors@Stimpy.netroedge.com
Subject: Re: [PATCH 2.6] Rework memory allocation in i2c chip drivers (second try)
Date: Sat, 17 Apr 2004 14:53:09 +0200 [thread overview]
Message-ID: <20040417145309.4831f2b6.khali@linux-fr.org> (raw)
In-Reply-To: <20040410165832.08e0c80d.khali@linux-fr.org>
> > > Instead of splitting one kmalloc in two, it would also be possible
> > > to add a "struct i2c_client client" field to each of the *_data
> > > structures - the compiler should align all fields appropriately.
> > > Probably this way will result in less changes to the code (and
> > > also less labels and less error paths).
> >
> > I like this version a lot better. It's simpler and if we do this,
> > we can easily switch to the proper refcount handling of the
> > i2c_client structures like we should do in 2.7.
> >
> > Jean, care to redo your patch in this form?
>
> OK, here you go. Thanks Sergey for the insightful example!
U-ho. I think I've introduced a memory leak with this patch :(
For drivers that handle subclients (asb100 and w83781d on i2c), the
sublient memory is never released if I read the code correctly. This is
because we now free the private data on unload, assuming that it
contains the i2c client data as well. That's true for the main i2c
client, but not for the subclients (data == NULL so nothing is freed).
Could someone take a look and confirm?
I can see two different fixes:
1* When freeing the memory, free the data if it's not NULL (main
client), else free client (subclients). Cleaner (I suppose?).
2* When creating subclients, do data = &client instead of data = NULL.
Then freeing will work. Less code, faster. Are there side effects? (I
don't think so)
My preference would go to 2*.
Thanks.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
next prev parent reply other threads:[~2004-04-17 12:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-03 17:10 [RFC 2.6] Rework memory allocation in i2c chip drivers Jean Delvare
2004-04-03 19:07 ` Geert Uytterhoeven
2004-04-03 20:20 ` Sergey Vlasov
2004-04-09 17:31 ` Greg KH
2004-04-10 14:58 ` [PATCH 2.6] Rework memory allocation in i2c chip drivers (second try) Jean Delvare
2004-04-17 12:53 ` Jean Delvare [this message]
2004-04-18 6:01 ` Jean Delvare
2004-05-02 20:06 ` [PATCH 2.6] Fix memory leaks in w83781d and asb100 Jean Delvare
2004-05-05 22:18 ` Greg KH
2004-05-07 12:42 ` Jean Delvare
2004-05-07 22:34 ` Greg KH
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=20040417145309.4831f2b6.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@Stimpy.netroedge.com \
--cc=vsu@altlinux.ru \
/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