From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: question about drivers/pinctrl/pinctrl-at91.c
Date: Tue, 11 Dec 2012 09:06:59 +0000 [thread overview]
Message-ID: <20121211090659.DAC4C3E076D@localhost> (raw)
In-Reply-To: <alpine.DEB.2.02.1212081643590.1984@hadrien>
On Sat, 8 Dec 2012 16:52:42 +0100 (CET), Julia Lawall <julia.lawall@lip6.fr> wrote:
> The function at91_dt_node_to_map in drivers/pinctrl/pinctrl-at91.c
> contains the following code:
>
> new_map = devm_kzalloc(pctldev->dev, sizeof(*new_map) * map_num, GFP_KERNEL);
> if (!new_map)
> return -ENOMEM;
>
> *map = new_map;
> *num_maps = map_num;
>
> /* create mux map */
> parent = of_get_parent(np);
> if (!parent) {
> kfree(new_map);
> return -EINVAL;
> }
>
> This is clearly not correct, because the combination of devm_kzalloc and
> kfree risks creating a double free. But I am not sure how best to fix it.
> Is the data structure intended to normally exist until the driver's remove
> function is called? If so, perhaps the devm_kzalloc is OK. If I just
> remove the kfree, then the structure will persist until the remove
> function is called, even though there was an error, which is perhaps not
> good. So I could change the kfree to devm_kfree?
Hi Julia,
I don't have that file in my tree. Is it in linux-next? (I'm too lazy to
go and look)
Yes, devm_kfree() is the right thing to call, but I'd be tempted to just
drop the free entirely. If it fails there is something wrong and it will
get cleaned up when the probe returns a fail code... but look at the
code; if failing there is a valid way for the driver to operate, then
doing the cleanup is the right thing....
Alternately the of_get_parent() call could simply be moved above the
devm_kzalloc() and then the issue becomes moot. :-)
g.
prev parent reply other threads:[~2012-12-11 9:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-08 15:52 question about drivers/pinctrl/pinctrl-at91.c Julia Lawall
2012-12-11 8:51 ` Linus Walleij
2012-12-11 9:04 ` Julia Lawall
2012-12-11 9:08 ` Linus Walleij
2012-12-11 9:59 ` Julia Lawall
2012-12-11 9:06 ` Grant Likely [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=20121211090659.DAC4C3E076D@localhost \
--to=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.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).