Hi, Thank you for the suggestions. On Thu, Dec 29, 2011 at 6:40 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> 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@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
