Re: Slab corruption after unloading a module

[zhiyi huang <hzy@cs.otago.ac.nz>]

> On Sun, 16 Apr 2006 19:17:41 -0700 Randy.Dunlap wrote:
>
> > On Sun, 16 Apr 2006 21:38:44 +1200 zhiyi huang wrote:
> >
> > > On 16/04/2006, at 4:21 PM, Randy.Dunlap wrote:
> > >
> > > > On Thu, 13 Apr 2006 11:04:39 +1200 Zhiyi Huang wrote:
> > > >
> > > > > > 2.6.8 is an old kernel, you could very well be hitting a  
> > > > > > kernel bug
> > > > > > that has been fixed already. Can you reproduce this with 2.6.16?
> > > > >
> > > > > I will try that soon.
> > > > >
> > > > > > Also,
> > > > > > you're not including sources to your module so it's impossible to
> > > > > > tell
> > > > > > whether you're doing something wrong.
> > > > > >
> > > > > >                                                          Pekka
> > > > >
> > > > > Below is my baby module which only uses kmalloc and kfree for my
> > > > > device
> > > > > structure. I found the slab corruption address is the address of
> > > > > the structure.
> > > > > It seems to be a bug for kmalloc and kfree.
> > > >
> > > > > /* The parameter for testing */
> > > > > int major=0;
> > > > > MODULE_PARM(major, "i");
> > > > > MODULE_PARM_DESC(major, "device major number");
> > > >
> > > > Hi,
> > > > I had no problem loading and unloading your module on
> > > > 2.6.17-rc1 [after changing MODULE_PARM() to
> > > > module_param(major, int, 0644);
> > > > ].
> > > >
> > > > ---
> > > > ~Randy
> > >
> > > There was no problem if I just load and unload the module. But if I
> > > write to the device using "ls > /dev/temp" and then unload the
> > > module, I would get slab corruption.  I tried to install 2.6.16.5 at
> > > the moment but got stuck when I was making an initrd image file (no
> > > output file produced! and no errors displayed). Once I get around
> > > this problem, I should be able to test it on the new kernel.
> > > Zhiyi
> >
> > Hm, OK, somehow I missed that crucial part.  Yes, my kernel now dies
> > a horrible death after I unload the tem module, but not with slab
> > corruption, just with invalid memory pointers.  Anyway, the most
> > obvious hint in your earlier email was the data values that were
> > printed:
> >
> > Slab corruption: start=c7933c38, len=192
> > Redzone: 0x5a2cf071/0x5a2cf071.
> > Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
> > 070: 6b 6b 6b 6b ac 3c 93 c7 ac 3c 93 c7 6b 6b 6b 6b
> > Prev obj: start=c7933b6c, len=192
> > Redzone: 0x5a2cf071/0x5a2cf071.
> > Last user: [<00000000>](0x0)
> > 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Next obj: start=c7933d04, len=192
> > Redzone: 0x5a2cf071/0x5a2cf071.
> > Last user: [<c01e58fa>](__journal_remove_checkpoint+0x4a/0xa0)
> > 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Aside from the obvious slab corruption and redzone error,
> > the 0x6b value is what mm/slab.c uses for use-after-free
> > poisoning, so it seems that there are some pointers out in
> > never-never land somewhere.
> >
> >
> > from mm/slab.c:
> > #define	POISON_INUSE	0x5a	/* for use-uninitialised poisoning */
> > #define POISON_FREE	0x6b	/* for use-after-free poisoning */
> > #define	POISON_END	0xa5	/* end-byte of poisoning */
>
>
> I don't see problems after I move the kfree() to after the call
> to unregister_chrdev_region().  Sounds like a good plan to make
> that change.
>
> ---
> ~Randy

I just did the same for my 2.6.8 kernel, but I still have similar  
problem. Below is the dmesg. Sometimes the problem didn't appear the  
first time you load the module. You may need to repeat what you did  
(i.e. load the module, write to the device, and then unload the  
module) before the problem appear.

Hello world from Template Module
temp device MAJOR is 253, dev addr: c51d0000
Good bye from Template Module
Slab corruption: start=c51d0000, len=4096
c60: 6b 6b 6b 6b 6b 6b 6b 6b 68 0c 1d c5 68 0c 1d c5

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