Re: [PULL] param sysfs oops (simple, leaky) fix, bool arrays fix

[Artem Bityutskiy <dedekind1@gmail.com>]

On Wed, 2010-05-05 at 09:44 +0200, Takashi Iwai wrote:
> At Wed, 05 May 2010 10:25:14 +0300,
> Artem Bityutskiy wrote:
> > 
> > On Wed, 2010-05-05 at 15:03 +0930, Rusty Russell wrote:
> > > On Wed, 5 May 2010 03:37:19 am Artem Bityutskiy wrote:
> > > > On Tue, 2010-05-04 at 11:53 +0930, Rusty Russell wrote:
> > > > > On Tue, 27 Apr 2010 08:23:24 pm Artem Bityutskiy wrote:
> > > > > > 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?
> > > > > 
> > > > > Yep!
> > > > 
> > > > Are you working/planning to work on fixing this regression?
> > > 
> > > 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.
> > 
> > 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. 
> 
> I don't think there are so many real cases that actually do leaking.

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"

They are potentially affected too.

> This is only for charp type parameters (not string), and no leak
> happens unless user gives the value explicitly via a module option.

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
having (even though small) memory leak.

> 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...

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 (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/