From: Rusty Russell <rusty@rustcorp.com.au>
To: Takashi Iwai <takashi.iwai@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: Problems with string (charp) module parameters
Date: Fri, 23 Oct 2009 00:50:41 +1030 [thread overview]
Message-ID: <200910230050.41790.rusty@rustcorp.com.au> (raw)
In-Reply-To: <6dc076840910211913l1cf12e82tbb9151da78e41422@mail.gmail.com>
On Thu, 22 Oct 2009 12:43:36 pm Takashi Iwai wrote:
> Hi Rusty,
>
> (sending from gmail address since VPN doesn't work here in hotel...)
>
> On Wed, Oct 21, 2009 at 3:11 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > On Tue, 13 Oct 2009 09:07:46 pm Takashi Iwai wrote:
> >> * 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.
> >
> > Yes, an array of charp isn't going to work. Erk, I switched one bug for
> > another :(
> >
> >> 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?
> >
> > Yes, that's hard. There's only one place which currently has a writable
> > array parameter: drivers/usb/atm/ueagle-atm.c, and it's root only.
> >
> > OK, for 2.6.32, we remove the const. In the longer term, I'm reworking how
> > this is done entirely.
>
> As far as I checked, removing only const doesn't suffice on x86.
> The problem is rather the __param section assignment.
> We'd need to get rid of that, too, if we keep the code in the current way.
Something like this?
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -147,6 +147,10 @@
MEM_KEEP(init.data) \
MEM_KEEP(exit.data) \
. = ALIGN(8); \
+ VMLINUX_SYMBOL(__start___param) = .; \
+ *(__param) \
+ VMLINUX_SYMBOL(__stop___param) = .; \
+ . = ALIGN(8); \
VMLINUX_SYMBOL(__start___markers) = .; \
*(__markers) \
VMLINUX_SYMBOL(__stop___markers) = .; \
@@ -336,15 +340,7 @@
MEM_KEEP(init.rodata) \
MEM_KEEP(exit.rodata) \
} \
- \
- /* Built-in module parameters. */ \
- __param : AT(ADDR(__param) - LOAD_OFFSET) { \
- VMLINUX_SYMBOL(__start___param) = .; \
- *(__param) \
- VMLINUX_SYMBOL(__stop___param) = .; \
- . = ALIGN((align)); \
- VMLINUX_SYMBOL(__end_rodata) = .; \
- } \
+ VMLINUX_SYMBOL(__end_rodata) = .; \
. = ALIGN((align));
/* RODATA & RO_DATA provided for backward compatibility.
This would work for 2.6.32, for 2.6.33 I have a different solution.
> It's not only for avoiding the mess to separate static and kmalloc
> strings but also for
> avoiding races between the referrer and the sysfs-write of char
> pointer. (In general, we
> have no lock for parameters.)
Good point. We should use rcu here. But there's still a race with copying
in strings of any kind.
> As you pointed out, there are no many users of writable charp parameters.
> So, replacing is easy task. In that way, we can keep struct
> kernel_parameter as const
> gracefully without hustling any big code change.
But we'd need to make sure noone adds one in future. After all, you tried
to add one and found this problem!
I'll post my current patch series: it needs testing, but I'd appreciate
your thoughts.
Thanks!
Rusty.
next prev parent reply other threads:[~2009-10-22 14:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-13 10:37 Problems with string (charp) module parameters Takashi Iwai
2009-10-21 13:11 ` Rusty Russell
2009-10-22 2:13 ` Takashi Iwai
2009-10-22 14:20 ` Rusty Russell [this message]
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=200910230050.41790.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=takashi.iwai@gmail.com \
--cc=tiwai@suse.de \
/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