From: Takashi Iwai <tiwai@suse.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Problems with string (charp) module parameters
Date: Tue, 13 Oct 2009 12:37:46 +0200 [thread overview]
Message-ID: <s5haazv1sw5.wl%tiwai@suse.de> (raw)
Hi Rusty,
While I tried to add some debug option to a driver, I found that a module
parameter taking a string (charp) gives Oops when set via sysfs:
BUG: unable to handle kernel paging request at ffffffff814c8d8a
IP: [<ffffffff8107b1ec>] param_set_charp+0x89/0xd0
PGD 1003067 PUD 1007063 PMD 11c10d063 PTE 80000000014c8161
Oops: 0003 [#1] SMP
...
Call Trace:
[<ffffffff8107a711>] param_attr_store+0x31/0x56
[<ffffffff8107a7b5>] module_attr_store+0x34/0x4c
[<ffffffff8117e300>] sysfs_write_file+0x101/0x151
[<ffffffff8111bf0c>] vfs_write+0xbc/0x195
[<ffffffff8134fb23>] ? do_page_fault+0x2e5/0x345
[<ffffffff8111c0d0>] sys_write+0x54/0x8f
[<ffffffff81011e82>] system_call_fastpath+0x16/0x1b
This seems happening only with a built-in driver, not with a module.
The Oops appears at line 227 in kernel/params.c (as of 2.6.32-rc4),
if (slab_is_available()) {
==> kp->flags |= KPARAM_KMALLOCED;
*(char **)kp->arg = kstrdup(val, GFP_KERNEL);
if (!kp->arg)
return -ENOMEM;
Puzzling. So I looked into the relevant code, and found some deeper
problems.
* Each struct kernel_param instance is defined as const, and is put
into __param section, which is read-only.
I guess this causes the page fault above. And...
* The above NULL check is invalid. It should be
if (!*(char **)kp->arg)
return -ENOMEM
This is easy, however...
* The handling of parameter array is pretty buggy now.
kp->perm and kp->flags aren't properly initialized in
param_array(). Thus, you might call kfree() with invalid pointers,
or pass a wrong type for bool.
The first item was overlooked because there was no writable field
before the kmalloc'ed string was introduced. And, the current code
still works somehow for charp with param_array() just because a struct
kernel_param on stack is used there. But, this is also a buggy
implementation due to the third point. We didn't hint a bug because
the charp array contain usually NULL.
So, the situation looks messy right now, not only about the section
issue. If we allow kmalloc of each parameter array element, the flag
must be associated to each element, not a global one to the array.
Thoughts?
thanks,
Takashi
next reply other threads:[~2009-10-13 10:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-13 10:37 Takashi Iwai [this message]
2009-10-21 13:11 ` Rusty Russell
2009-10-22 2:13 ` Takashi Iwai
2009-10-22 14:20 ` Rusty Russell
2009-10-22 15:54 ` Paul E. McKenney
2009-10-23 14:48 ` Rusty Russell
2009-10-21 15:28 ` [PATCH 1/2] param: don't make the kernel_param's const Rusty Russell
2009-10-21 15:45 ` [PATCH 2/2] param: initialize flags when processing array Rusty Russell
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=s5haazv1sw5.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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
all inboxes | Powered by JetHome®