2010-03-03 10:22:46     param_set_charp memory seams to leak?

Document created by Aaronwu Employee on Aug 21, 2013
Version 1Show Document
  • View in full screen mode

2010-03-03 10:22:46     param_set_charp memory seams to leak?

Filip Van Rillaer (BELGIUM)

Message: 86759   

 

Hello,

 

A very simple module (see attachment) seems to leak memory:

insmod fivacharp.ko szTestName=blabla

rmmod fivacharp

 

however without parameter, it's working fine:

insmod fivacharp.ko

rmmod fivacharp

 

Please comment.

 

Best regards,

Filip

 

fivacharp.c

TranslateQuoteReplyEditDelete

 

 

2010-03-04 22:38:00     Re: param_set_charp memory seams to leak?

Mike Frysinger (UNITED STATES)

Message: 86818   

 

seems fine to me

 

root:/> insmod test.ko ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        15924        44452            0            0

root:/> insmod test.ko ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        15924        44452            0            0

root:/> insmod test.ko ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        15924        44452            0            0

QuoteReplyEditDelete

 

 

2010-03-05 05:06:58     Re: param_set_charp memory seams to leak?

Filip Van Rillaer (BELGIUM)

Message: 86856   

 

Hello Mike,

 

Thank you for your answer.  As far as I could see the memory leak is 32 bytes.  For my test, I used a (hush) script to automate the insmod/rmmod, but I don't think that that is related to the problem.  I compared /proc/slab_allocators before and after the test and saw that the param_set_charp count incremented for every loop of the test.  Setting the value of a module parameter is essential to see the problem ... I think that is missing in your test : insmod test.ko szTestName=blabla.

 

Best regards,

Filip

TranslateQuoteReplyEditDelete

 

 

2010-03-05 07:07:16     Re: param_set_charp memory seams to leak?

Mike Frysinger (UNITED STATES)

Message: 86857   

 

doesnt seem to make a difference:

root:/> insmod test.ko szTestName=blablaaaaaa ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        12772        47604            0            0

root:/> insmod test.ko szTestName=blablaaaaaa ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        12772        47604            0            0

root:/> insmod test.ko szTestName=blablaaaaaa ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        12772        47604            0            0

root:/> insmod test.ko szTestName=blablaaaaaa ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        12772        47604            0            0

root:/> insmod test.ko szTestName=blablaaaaaa ; rmmod test.ko ; sleep 1 ; free

              total         used         free       shared      buffers

  Mem:        60376        12772        47604            0            0

 

i dont have a /proc/slab_allocators so i cant check that ...

QuoteReplyEditDelete

 

 

2010-03-05 08:18:42     Re: param_set_charp memory seams to leak?

Filip Van Rillaer (BELGIUM)

Message: 86863   

 

Hello Mike,

 

I've done the test again, this time without using a script to run the test (just once insmod/rmmod).  My results are different from yours:

before the test: free -> Mem: 50960 9920 41040 0 8

after the test :   free -> Mem: 50960 9924 41036 0 8

/proc/slab_allocators shows only following difference:

size-32: 1 _param_set_charp+0x40/0x74

 

dmesg shows following lines, maybe this rings a bell???

kobject: 'fivacharp' (02bdb100): kobject_add_internal: parent: 'module', set: 'module'

kobject: 'holders' (02a59a0c): kobject_add_internal: parent: 'fivacharp', set: '<NULL>'

kobject: 'holders' (02a59a0c): kobject_cleanup

kobject: 'holders' (02a59a0c): auto cleanup kobject_del

kobject: 'holders' (02a59a0c): calling ktype release

kobject: (02a59a0c): dynamic_kobj_release

kobject: 'holders': free name

kobject: 'fivacharp' (02bdb100): kobject_cleanup

kobject: 'fivacharp' (02bdb100): does not have a release() function, it is broken and must be fixed.

kobject: 'fivacharp' (02bdb100): auto cleanup kobject_del

kobject: 'fivacharp': free name

 

BTW: I am working with a resent version of the kernel in subversion in trunk: rev 8373.

 

Best regards,

Filip

TranslateQuoteReplyEditDelete

 

 

2010-03-05 08:24:39     Re: param_set_charp memory seams to leak?

Mike Frysinger (UNITED STATES)

Message: 86864   

 

my tests are all done with the latest svn trunk

 

post your kernel .config

QuoteReplyEditDelete

 

 

2010-03-05 09:15:39     Re: param_set_charp memory seams to leak?

Filip Van Rillaer (BELGIUM)

Message: 86868   

 

I updated to the very latest revision : 8391

The problem is still there.

 

Please find in the attachent my kernel config

I am working on a BF537 Stamp board.

 

myconfig

TranslateQuoteReplyEditDelete

 

 

2010-03-09 18:22:43     Re: param_set_charp memory seams to leak?

Mike Frysinger (UNITED STATES)

Message: 87006   

 

thanks, i can reproduce now.  ive pushed it upstream as it seems to be an issue in common code that i'm not familiar with.

 

  bugzilla.kernel.org/show_bug.cgi?id=15500

QuoteReplyEditDelete

 

 

2010-04-28 09:05:04     Re: param_set_charp memory seams to leak?

Filip Van Rillaer (BELGIUM)

Message: 88993   

 

Hello Mike,

 

Thank you for logging the bug-rapport.

FYI: here is some recent information that is probably related to this memory leak.  So we still have to wait till they solve it.

 

  lkml.org/lkml/2010/4/27/150

 

<<

 

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?

 

>>

 

BR,

 

Filip

Attachments

Outcomes