Hi, Thank you for the suggestions. On Thu, Dec 29, 2011 at 6:40 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi.....
Nice name you have :)
Thank you, coming up with that was a no-brainer ;)
On Thu, Dec 29, 2011 at 11:27, contemplating zombie <contemplatingzombie@gmail.com> wrote:
Hi,
I have written a kernel module that does frequent memory allocs, reallocs and deallocs. The code randomly crashes at one of the two memory allocation parts - either in krealloc() or in kmem_cache_alloc_notrace (called by kmalloc()). However, when I analyzed both the crash points instructions using gdb, they both turned out to be at the same location in slab_alloc().
alright, all we know is that kmalloc and family eventually use slabs.
So, I suspect: 1. either there are flaws in slab management OR 2. you somehow corrupt the slab
I think number 1 is highly unlikely. I am focusing on number 2.
Since you don't let us see the code, I'll ask you back: 1. do you think somehow you feed data bigger than one allocated? 2. do you somehow do double free?
I think this could be the culprit. I am putting printk's before every alloc/free to check if this is happening.
3. regarding realloc...I personally don't really think it's better than alloc-free-alloc cycle. So, have you tried to convery your realloc call into alloc-free-alloc?
I will try this too, although I do not think this would be an issue.
About the GPF, i just sense it might be a terrible memory corrupt somewhere somehow, And usually, the root is overflow...
I agree. Just that don't know how to pinpoint it reliably. -ctmzb