* Re: Slab corruption after unloading a module
@ 2006-04-16 10:43 Andrey Borzenkov
2006-04-17 22:08 ` zhiyi huang
0 siblings, 1 reply; 12+ messages in thread
From: Andrey Borzenkov @ 2006-04-16 10:43 UTC (permalink / raw)
To: zhiyi huang; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> 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.
you return different value as what has really been consumed:
> if (*f_pos + count > MAX_DSIZE)
> count1 = MAX_DSIZE - *f_pos;
>
> if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
> rv = -EFAULT;
> goto wrap_up;
> }
> up (&temp_dev->sem);
> *f_pos += count1;
> return count;
may be it confuses the rest of kernel a bit?
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEQh/JR6LMutpd94wRAgn/AKCapb6QcSSeHn1X7qD1TxLBs2OCSACgnGg7
o7fTn3l6DTnLEr5EwqL7hjk=
=bHLf
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Slab corruption after unloading a module
2006-04-16 10:43 Slab corruption after unloading a module Andrey Borzenkov
@ 2006-04-17 22:08 ` zhiyi huang
2006-04-17 22:09 ` Arjan van de Ven
0 siblings, 1 reply; 12+ messages in thread
From: zhiyi huang @ 2006-04-17 22:08 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: linux-kernel
>
>> 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.
>
> you return different value as what has really been consumed:
>
>> if (*f_pos + count > MAX_DSIZE)
>> count1 = MAX_DSIZE - *f_pos;
>>
>> if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>> rv = -EFAULT;
>> goto wrap_up;
>> }
>> up (&temp_dev->sem);
>> *f_pos += count1;
>> return count;
>
> may be it confuses the rest of kernel a bit?
I did this intentionally. Since my baby device buffer is fixed size,
I can't overflow the buffer. What I do is to cheat the application
(by pretending the bytes requested are copied to the device) so that
the application will be happy and do not hang on to send to the
device again and again. After all it is a test module for char device.
Nevertheless, I don't think this cheating has something to do with
the slab corruption.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Slab corruption after unloading a module
2006-04-17 22:08 ` zhiyi huang
@ 2006-04-17 22:09 ` Arjan van de Ven
2006-04-17 22:23 ` zhiyi huang
0 siblings, 1 reply; 12+ messages in thread
From: Arjan van de Ven @ 2006-04-17 22:09 UTC (permalink / raw)
To: zhiyi huang; +Cc: Andrey Borzenkov, linux-kernel
On Tue, 2006-04-18 at 10:08 +1200, zhiyi huang wrote:
> >
> >> 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.
> >
> > you return different value as what has really been consumed:
> >
> >> if (*f_pos + count > MAX_DSIZE)
> >> count1 = MAX_DSIZE - *f_pos;
> >>
> >> if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
this is still buggy.. what if f_pos is huge???
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Slab corruption after unloading a module
2006-04-17 22:09 ` Arjan van de Ven
@ 2006-04-17 22:23 ` zhiyi huang
0 siblings, 0 replies; 12+ messages in thread
From: zhiyi huang @ 2006-04-17 22:23 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andrey Borzenkov, linux-kernel
> On Tue, 2006-04-18 at 10:08 +1200, zhiyi huang wrote:
>>>
>>>> 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.
>>>
>>> you return different value as what has really been consumed:
>>>
>>>> if (*f_pos + count > MAX_DSIZE)
>>>> count1 = MAX_DSIZE - *f_pos;
>>>>
>>>> if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>
> this is still buggy.. what if f_pos is huge???
Well, if you look at my program, the complete code is like this:
if (*f_pos > MAX_DSIZE)
goto wrap_up;
if (*f_pos + count > MAX_DSIZE)
count1 = MAX_DSIZE - *f_pos;
if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: Slab corruption after unloading a module
@ 2006-04-12 23:04 Zhiyi Huang
2006-04-12 23:30 ` Randy.Dunlap
2006-04-16 4:21 ` Randy.Dunlap
0 siblings, 2 replies; 12+ messages in thread
From: Zhiyi Huang @ 2006-04-12 23:04 UTC (permalink / raw)
To: Pekka Enberg, hzy; +Cc: Hareesh Nagarajan, linux-kernel, zhiyi6
> 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.
/
*----------------------------------------------------------------
------------*/
/* File: tem.c */
/* Date: 13/03/2006 */
/* Author: Zhiyi Huang */
/* Version: 0.1 */
/
*----------------------------------------------------------------
------------*/
/* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
#include <linux/config.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/proc_fs.h>
#include <linux/fcntl.h>
#include <linux/aio.h>
#include <asm/uaccess.h>
#include <linux/ioctl.h>
#include <linux/cdev.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Zhiyi Huang");
MODULE_DESCRIPTION("A template module");
/* The parameter for testing */
int major=0;
MODULE_PARM(major, "i");
MODULE_PARM_DESC(major, "device major number");
#define MAX_DSIZE 3071
struct my_dev {
char data[MAX_DSIZE+1];
size_t size; /* 32-bit will suffice */
struct semaphore sem; /* Mutual exclusion */
struct cdev cdev;
} *temp_dev;
int temp_open (struct inode *inode, struct file *filp)
{
return 0;
}
int temp_release (struct inode *inode, struct file *filp)
{
return 0;
}
ssize_t temp_read (struct file *filp, char __user *buf, size_t count,loff_t *f_pos)
{
int rv=0;
if (down_interruptible (&temp_dev->sem))
return -ERESTARTSYS;
if (*f_pos > MAX_DSIZE)
goto wrap_up;
if (*f_pos + count > MAX_DSIZE)
count = MAX_DSIZE - *f_pos;
if (copy_to_user (buf, temp_dev->data+*f_pos, count)) {
rv = -EFAULT;
goto wrap_up;
}
up (&temp_dev->sem);
*f_pos += count;
return count;
wrap_up:
up (&temp_dev->sem);
return rv;
}
ssize_t temp_write (struct file *filp, const char __user *buf, size_t count, loff_t
*f_pos)
{
int count1=count, rv=count;
if (down_interruptible (&temp_dev->sem))
return -ERESTARTSYS;
if (*f_pos > MAX_DSIZE)
goto wrap_up;
if (*f_pos + count > MAX_DSIZE)
count1 = MAX_DSIZE - *f_pos;
if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
rv = -EFAULT;
goto wrap_up;
}
up (&temp_dev->sem);
*f_pos += count1;
return count;
wrap_up:
up (&temp_dev->sem);
return rv;
}
int temp_ioctl (struct inode *inode, struct file *filp,unsigned int cmd,
unsigned long arg)
{
return 0;
}
loff_t temp_llseek (struct file *filp, loff_t off, int whence)
{
long newpos;
switch(whence) {
case 0: /* SEEK_SET */
newpos = off;
break;
case 1: /* SEEK_CUR */
newpos = filp->f_pos + off;
break;
case 2: /* SEEK_END */
newpos = temp_dev->size + off;
break;
default: /* can't happen */
return -EINVAL;
}
if (newpos<0 || newpos>MAX_DSIZE) return -EINVAL;
filp->f_pos = newpos;
return newpos;
}
struct file_operations temp_fops = {
.owner = THIS_MODULE,
.llseek = temp_llseek,
.read = temp_read,
.write = temp_write,
.ioctl = temp_ioctl,
.open = temp_open,
.release = temp_release,
};
/**
* Initialise the module and create the master device
*/
int __init tem_init_module(void){
int rv;
dev_t devno = MKDEV(major, 0);
if(major) {
rv = register_chrdev_region(devno, 1, "temp");
if(rv < 0){
printk(KERN_WARNING "Can't use the major number %d; try
atomatic allocation...\n", major);
rv = alloc_chrdev_region(&devno, 0, 1, "temp");
major = MAJOR(devno);
}
}
else {
rv = alloc_chrdev_region(&devno, 0, 1, "temp");
major = MAJOR(devno);
}
if(rv < 0) return rv;
temp_dev = kmalloc(sizeof(struct my_dev), GFP_KERNEL);
if(temp_dev == NULL){
rv = -ENOMEM;
unregister_chrdev_region(devno, 1);
return rv;
}
memset(temp_dev, 0, sizeof(struct my_dev));
cdev_init(&temp_dev->cdev, &temp_fops);
temp_dev->cdev.owner = THIS_MODULE;
temp_dev->cdev.ops = &temp_fops;
temp_dev->size = MAX_DSIZE;
sema_init (&temp_dev->sem, 1);
rv = cdev_add (&temp_dev->cdev, devno, 1);
if (rv) printk(KERN_WARNING "Error %d adding device temp", rv);
printk(KERN_WARNING "Hello world from Template Module\n");
printk(KERN_WARNING "temp device MAJOR is %d, dev addr: %lx\n",
major, (unsigned long)temp_dev);
return 0;
}
/**
* Finalise the module
*/
void __exit tem_exit_module(void){
kfree(temp_dev);
unregister_chrdev_region(MKDEV(major, 0), 1);
printk(KERN_WARNING "Good bye from Template Module\n");
}
module_init(tem_init_module);
module_exit(tem_exit_module);
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Slab corruption after unloading a module
2006-04-12 23:04 Zhiyi Huang
@ 2006-04-12 23:30 ` Randy.Dunlap
2006-04-16 4:21 ` Randy.Dunlap
1 sibling, 0 replies; 12+ messages in thread
From: Randy.Dunlap @ 2006-04-12 23:30 UTC (permalink / raw)
To: hzy; +Cc: zhiyi6, penberg, hnagar2, linux-kernel
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.
I haven't looked at your source code yet, but in addition to testing with a
recent kernel version, it may help to enable lots of kernel debug options.
Could you try that too, or do you already do that?
---
~Randy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Slab corruption after unloading a module
2006-04-12 23:04 Zhiyi Huang
2006-04-12 23:30 ` Randy.Dunlap
@ 2006-04-16 4:21 ` Randy.Dunlap
2006-04-16 9:38 ` zhiyi huang
1 sibling, 1 reply; 12+ messages in thread
From: Randy.Dunlap @ 2006-04-16 4:21 UTC (permalink / raw)
To: hzy; +Cc: zhiyi6, penberg, hnagar2, linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Slab corruption after unloading a module
2006-04-16 4:21 ` Randy.Dunlap
@ 2006-04-16 9:38 ` zhiyi huang
2006-04-17 2:17 ` Randy.Dunlap
0 siblings, 1 reply; 12+ messages in thread
From: zhiyi huang @ 2006-04-16 9:38 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: penberg, hnagar2, linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Slab corruption after unloading a module
2006-04-16 9:38 ` zhiyi huang
@ 2006-04-17 2:17 ` Randy.Dunlap
2006-04-17 2:55 ` Randy.Dunlap
0 siblings, 1 reply; 12+ messages in thread
From: Randy.Dunlap @ 2006-04-17 2:17 UTC (permalink / raw)
To: zhiyi huang; +Cc: penberg, hnagar2, linux-kernel
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 */
---
~Randy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Slab corruption after unloading a module
2006-04-17 2:17 ` Randy.Dunlap
@ 2006-04-17 2:55 ` Randy.Dunlap
2006-04-17 21:49 ` zhiyi huang
0 siblings, 1 reply; 12+ messages in thread
From: Randy.Dunlap @ 2006-04-17 2:55 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: hzy, penberg, hnagar2, linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Slab corruption after unloading a module
2006-04-17 2:55 ` Randy.Dunlap
@ 2006-04-17 21:49 ` zhiyi huang
2006-04-18 5:01 ` Randy.Dunlap
0 siblings, 1 reply; 12+ messages in thread
From: zhiyi huang @ 2006-04-17 21:49 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: penberg, hnagar2, linux-kernel
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Slab corruption after unloading a module
2006-04-17 21:49 ` zhiyi huang
@ 2006-04-18 5:01 ` Randy.Dunlap
0 siblings, 0 replies; 12+ messages in thread
From: Randy.Dunlap @ 2006-04-18 5:01 UTC (permalink / raw)
To: zhiyi huang; +Cc: penberg, hnagar2, linux-kernel
On Tue, 18 Apr 2006 09:49:13 +1200 zhiyi huang wrote:
>
> > 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
OK, on the third run of the test, my kernel dies (not slab
corruption). I don't have time to dig into it tonight...
---
~Randy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Slab corruption after unloading a module
@ 2006-04-12 0:37 Zhiyi Huang
0 siblings, 0 replies; 12+ messages in thread
From: Zhiyi Huang @ 2006-04-12 0:37 UTC (permalink / raw)
To: linux-kernel; +Cc: zhiyi6
Hi there, I am a bit timid to post a message to the list after reading the FAQ,
but I did get a problem. When reply, please cc to my email address.
My kernel info: Linux version 2.6.8 (root@zhiyi) (gcc version 3.3.5 (Debian
1:3.3.5-8)) #1
Everytime (except the first time) I unload my module (a ram device), I got the
following message. Please just indicate if it is a kernel bug or if there is any
fix patch. At the moment I have no clue. I used kmalloc and alloc_page to
allocate memory dynamically when the ram device grows. And I freed them
when the module is unloaded of course.
Hello world from Template Module
temp device MAJOR is 253
Good bye from Template Module: 618 pages
Hello world from Template Module
temp device MAJOR is 253
Good bye from Template Module: 618 pages
Slab corruption: start=c7c12d24, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
070: 6b 6b 6b 6b 98 2d c1 c7 98 2d c1 c7 6b 6b 6b 6b
Prev obj: start=c7c12c58, len=192
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c01ac52d>](load_elf_interp+0xdd/0x2d0)
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=c7c12df0, 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-04-18 4:59 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-16 10:43 Slab corruption after unloading a module Andrey Borzenkov
2006-04-17 22:08 ` zhiyi huang
2006-04-17 22:09 ` Arjan van de Ven
2006-04-17 22:23 ` zhiyi huang
-- strict thread matches above, loose matches on Subject: below --
2006-04-12 23:04 Zhiyi Huang
2006-04-12 23:30 ` Randy.Dunlap
2006-04-16 4:21 ` Randy.Dunlap
2006-04-16 9:38 ` zhiyi huang
2006-04-17 2:17 ` Randy.Dunlap
2006-04-17 2:55 ` Randy.Dunlap
2006-04-17 21:49 ` zhiyi huang
2006-04-18 5:01 ` Randy.Dunlap
2006-04-12 0:37 Zhiyi Huang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®