From: Rusty Russell <rusty@rustcorp.com.au>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: David Woodhouse <David.Woodhouse@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Arjun Sreedharan <arjun024@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: krealloc in kernel/params.c
Date: Fri, 17 Oct 2014 09:29:27 +1030 [thread overview]
Message-ID: <87wq7zaaeo.fsf@rustcorp.com.au> (raw)
In-Reply-To: <87fveo1h07.fsf@rasmusvillemoes.dk>
Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
> On Wed, Oct 15 2014, Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>> Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
>> The kzalloc-then-always-krealloc pattern is perhaps overly simplistic,
>> but this code has clearly confused people. It worked on me...
>>
>
> I think kzalloc immediately followed by kreallocing the returned value
> is rather ugly. Other than that:
Indeed, but it's an obvious pattern. "If not initialized, initialize".
>> - num = mk->mp->num;
>> - attrs = mk->mp->grp.attrs;
>> + /* First allocation. */
>> + mk->mp = kzalloc(sizeof(*mk->mp), GFP_KERNEL);
>> + if (!mk->mp)
>> + return -ENOMEM;
>
> free_module_param_attrs does not check mk->mp for being NULL before
> kfree'ing mk->mp->grp.attrs, so this will oops.
Nice catch, folded this in:
diff --git a/kernel/params.c b/kernel/params.c
index 3ebe6c64aa67..ee92e67f2cee 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -650,7 +650,8 @@ static __modinit int add_sysfs_param(struct module_kobject *mk,
#ifdef CONFIG_MODULES
static void free_module_param_attrs(struct module_kobject *mk)
{
- kfree(mk->mp->grp.attrs);
+ if (mk->mp)
+ kfree(mk->mp->grp.attrs);
kfree(mk->mp);
mk->mp = NULL;
}
Thanks!
Rusty.
prev parent reply other threads:[~2014-10-16 23:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 20:44 krealloc in kernel/params.c Rasmus Villemoes
2014-10-15 4:59 ` Rusty Russell
2014-10-16 9:49 ` Rasmus Villemoes
2014-10-16 22:59 ` Rusty Russell [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=87wq7zaaeo.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=David.Woodhouse@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arjun024@gmail.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.