(Thanks to Takashi-san, who found the oops and kept reading the code to spot
 the others.  A more complete fix is pending, but this works for 2.6.32 and
 -stable: see commit message and FIXME in code.)

The following changes since commit 964fe080d94db82a3268443e9b9ece4c60246414:
  Linus Torvalds (1):
        Merge git://git.kernel.org/.../rusty/linux-2.6-for-linus

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-param-fixes.git master

Rusty Russell (3):
      param: fix lots of bugs with writing charp params from sysfs, by leaking mem.
      param: fix NULL comparison on oom
      param: fix setting arrays of bool

 include/linux/moduleparam.h |    1 -
 kernel/params.c             |   17 ++++++-----------
 2 files changed, 6 insertions(+), 12 deletions(-)

commit 65afac7d80ab3bc9f81e75eafb71eeb92a3ebdef
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Thu Oct 29 08:56:16 2009 -0600

    param: fix lots of bugs with writing charp params from sysfs, by leaking mem.
    
    e180a6b7759a "param: fix charp parameters set via sysfs" fixed the case
    where charp parameters written via sysfs were freed, leaving drivers
    accessing random memory.
    
    Unfortunately, storing a flag in the kparam struct was a bad idea: it's
    rodata so setting it causes an oops on some archs.  But that's not all:
    
    1) module_param_array() on charp doesn't work reliably, since we use an
       uninitialized temporary struct kernel_param.
    2) there's a fundamental race if a module uses this parameter and then
       it's changed: they will still access the old, freed, memory.
    
    The simplest fix (ie. for 2.6.32) is to never free the memory.  This
    prevents all these problems, at cost of a memory leak.  In practice, there
    are only 18 places where a charp is writable via sysfs, and all are
    root-only writable.
    
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Cc: Sitsofe Wheeler ...
[ message continues ]

Hmm, is it really only about changing the parameters via sysfs? We see
the following kmemleak complaints in 2.6.32 (I think it will be the same
in the latest kernel, but I did not check):

kmemleak: unreferenced object 0xdeff3c80 (size 64):
kmemleak:   comm "modprobe", pid 788, jiffies 4294933427
kmemleak:   backtrace:
kmemleak:     [<c00e59b8>] __save_stack_trace+0x34/0x40
kmemleak:     [<c00e5ad0>] create_object+0x10c/0x208
kmemleak:     [<c03ae0ec>] kmemleak_alloc+0x40/0x84
kmemleak:     [<c00dca74>] __kmalloc_track_caller+0x140/0x154
kmemleak:     [<c00c47ac>] kstrdup+0x38/0x54
kmemleak:     [<c0081854>] param_set_charp+0x68/0x94
kmemleak:     [<c0081108>] parse_args+0x18c/0x280
kmemleak:     [<c009fc74>] load_module+0x11e8/0x1644
kmemleak:     [<c00a0130>] sys_init_module+0x60/0x1f4
kmemleak:     [<c003c040>] ret_fast_syscall+0x0/0x38

So we are leaking on every insmod/rmmod, AFAICS, not just in the sysfs
case.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--

[ message continues ]

Rusty, correct me if I'm wrong, but it looks like the above memleak was
introduced by e180a6b7759a99a28cbcce3547c4c80822cb6c2a, where you added
the kstrdup(). So you kinda fixed the sysfs case (it still memleaks
though), but at the cost of additional insmod/rmmod leak, right?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--

[ message continues ]

Yep!

Cheers,
Rusty.
--

[ message continues ]

Are you working/planning to work on fixing this regression?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--

[ message continues ]

I'm still ambivalent on it; I have patches but it's a lot of churn for not
much gain.

To fix this, we need a way to lock parameters against changing by sysfs, and
we need to use it everywhere.  Past experience has demonstrated that this will
never be maintained.  

On the other hand, the leak is trivial.

Here's a git tree if you want to look further:

The following changes since commit 05ce7bfe547c9fa967d9cab6c37867a9cb6fb3fa:
  Linus Torvalds (1):
        Merge branch 'for_linus' of git://git.kernel.org/.../jack/linux-fs-2.6

are available in the git repository at:

  git://git.kernel.org/rusty/linux-2.6-param-fixes.git master

Rusty Russell (17):
      param: move the EXPORT_SYMBOL to after the definitions.
      params: don't hand NULL values to param.set callbacks.
      param: use ops in struct kernel_param, rather than get and set fns directly
      param: silence .init.text references from param ops
      param: add a free hook to kernel_param_ops.
      param: use free hook for charp
      param: make param sections const.
      param: locking for kernel parameters
      param: add kerneldoc
      param: remove unnecessary writable charp
      param: simple locking for sysfs-writable charp parameters
      param: lock myri10ge_fw_name against sysfs changes.
      param: lock if_sdio's lbs_helper_name and lbs_fw_name against sysfs changes.
      param: update drivers/char/ipmi/ipmi_watchdog.c to new scheme
      ide: use module_param_named rather than module_param_call
      param: use module_param in drivers/message/fusion/mptbase.c
      param: update drivers/acpi/debug.c to new scheme

Sachin Sant (1):
      Add param ops struct for hvc_iucv driver.

 arch/um/drivers/hostaudio_kern.c          |   10 +
 drivers/acpi/debug.c                      |   32 +++-
 drivers/char/hvc_iucv.c                   |    9 +-
 drivers/char/ipmi/ipmi_watchdog.c         |   42 +++--
 drivers/ide/ide.c                         |   20 ++-
 drivers/input/misc/ati_remote2.c   ...
[ message continues ]

Well, I am not very concerned with the "changing by sysfs" leak. This is
not a big deal, IMHO. I am concerned with the "rmmod" leak, which did
not exist before your patches, but exists now. People may do a lot of
insmod/rmmod, and on each rmmod they will loose this kstrdup-ed string. 


Just in case others will clone, the correct URL seems to be

git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-param-fixes.git master

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--

[ message continues ]

At Wed, 05 May 2010 10:25:14 +0300,

I don't think there are so many real cases that actually do leaking.
This is only for charp type parameters (not string), and no leak
happens unless user gives the value explicitly via a module option.

Fixing in the way of the later upstream is a bit too intrusive as a
stable patch.  So, I'm also not sure whether we should take it,
too...


thanks,

Takashi
--

[ message continues ]

I am sorry, but let me disagree. Did you count these cases? Why are you
so sure?

We are one live case. We use drivers/usb/gadget/nokia.c. And this is
also used in production, in the Nokia N900 phone. 

IOW, I officially confirm that we are affected by this regression.

And there are many other potential charp users in drivers/usb/gadget.
Take a look at drivers/usb/gadget/composite.c:

static char *iManufacturer;
module_param(iManufacturer, charp, 0);
MODULE_PARM_DESC(iManufacturer, "USB Manufacturer string");

static char *iProduct;
module_param(iProduct, charp, 0);
MODULE_PARM_DESC(iProduct, "USB Product string");

static char *iSerialNumber;
module_param(iSerialNumber, charp, 0);
MODULE_PARM_DESC(iSerialNumber, "SerialNumber string");

This file is included from many other files:

[dedekind@eru gadget]$ pwd
/home/dedekind/git/linux-2.6-param-fixes/drivers/usb/gadget
[dedekind@eru gadget]$ grep 'composite.c' *
audio.c:#include "composite.c"
cdc2.c:#include "composite.c"
composite.c: * composite.c - infrastructure for Composite USB Gadgets
ether.c:#include "composite.c"
mass_storage.c:#include "composite.c"
multi.c:#include "composite.c"
nokia.c:#include "composite.c"
serial.c:#include "composite.c"
zero.c:#include "composite.c"


We do use these options. Surely, if they exist, people probably use at
least some of them, right? Otherwise why would they exist?

And I officially confirm that we load/unload the g_nokia gadget
(corresponds to nokia.c) many times, and we are not very interested in

To be frank I do not really understand what you mean.

Anyway, I just humbly suggest not to have the "no one uses that, let's
have a leak" attitude. I do understand that this is a 'it's a lot of
churn for not much gain'. However, I think the rmmod leak is large
enough issue.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--

[ message continues ]

If you meant 'let's not change it 2.6.34' - fair enough, it was already
in 2.6.32, so there is probably no reason to hurry. But I suggest to
still consider this as a big issue and fix as soon as we can.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--

[ message continues ]

At Wed, 05 May 2010 12:04:18 +0300,

Ah, sorry I was confused.  I somehow thought Rusty's patch has been
already merged after 2.6.32, but it didn't happen in reality.

Then I'm for merging the changes even for 2.6.34 although it's late.
In the API side, there aren't many changes.  And it might reduce the
whole binary size in the end by the use of module_parm_ops pointer,
too.


thanks,

Takashi
--

[ message continues ]

Thanks Artem, that's exactly the kind of feedback we need.

For most people, module parameters are rare, and module removal is rare.
So the amount of leak is less than the size of the code we would add to fix
it.

If this is hitting you, it clearly changes the priorities.  I will include
the patches now.

Thanks!
Rusty.

--

[ message continues ]

Rusty,

Artem's passed the baton over to me to investigate, so I've reviewed
and back-ported the last known version of your patchset. I'm happy to 
report that the 100% reproducable leak that we were seeing before
cannot be reproduced. As expected, given review of the code. I have 
not been able to test the final driver-specific patches from your 
patchset, but up to and including

[PATCH 12/18] param: simple locking for sysfs-writable charp parameters

they can all have a:

Tested-by: Phil Carmody <ext-phil.2.carmody@nokia.com>

I'm quite interested to see these pushed into the mainline so that I
can cherry-pick final versions for our internal tree, do you have any 
schedule for that?

Cheers,
Phil
--

[ message continues ]

Thanks, Phil, I've added that.  Testing is always good!

The patches are sitting in linux-next now, ready for the next merge window
(ie. 2.6.36)

Cheers,
Rusty.
--

[ message continues ]