* vmalloc memory corruption
@ 2005-01-04 21:24 Christian Gan
2005-01-04 21:24 ` Christian Gan
0 siblings, 1 reply; 5+ messages in thread
From: Christian Gan @ 2005-01-04 21:24 UTC (permalink / raw)
To: linux-mips
Hey all,
I'm running into a strange memory corruption problem while trying to get
a driver to load firmware using hotplug support on a DBAU1550 eval
board. This board has a single AU1550 MIPS32 processor. I'm running
kernel version 2.6.10-rc3.
I've attached a code snippet below that I'd like somebody to try to
verify for me so I can determine whether or not it is a problem with my
kernel/hardware.
The test code is a simplified version of the interaction between the
driver and the firmware/hotplug support of the kernel. The firmware
hotplug support (linux/drivers/base/firmware_class.c) if fed data from a
file and places it into a buffer, this buffer gets reallocated when
required and grows as more data is read in. Old data is memcopied into
the new reallocated buffer and newly read data is appended to the end.
What I'm finding is that eventually this data is corrupted.
Compile the test snippet below as a module and insmod it. If things are
successful you should see results like this:
# insmod vmalloctest.ko
Using vmalloctest.ko
testing vmalloc
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
...
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
But if data changes at any time, you've got problems like me. When I
run this on my platform eventually the data becomes all 0x00.
Notice that if you use kmalloc instead of vmalloc (define USE_KMALLOC),
everything works.
Thanks!
Christian Gan
// Start vmalloctest.c
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/vmalloc.h>
#include <asm/io.h>
//#define USE_KMALLOC
void fillbuf(char * buf, unsigned long len)
{
int i = 0;
for (i = 0; i < len; i++)
{
buf[i] = 0xFF & i;
}
}
int __init vmalloctest_init(void)
{
char * buf = NULL;
int i = 0;
printk("testing vmalloc\n");
for (i = 0; i < 50; i++)
{
int j = 0;
#ifndef USE_KMALLOC
char * newbuf = vmalloc( (i+1)*PAGE_SIZE );
// allocate a new buffer that grows in size
#else
char * newbuf = kmalloc( (i+1)*PAGE_SIZE, GFP_KERNEL );
// allocate a new buffer that grows in size
#endif
if (!newbuf)
{
printk("Could not allocate memory: %ld bytes\n",
(i+1)*PAGE_SIZE);
break;
}
if (i==0)
{
fillbuf(newbuf, PAGE_SIZE ); // fill
the original buffer with some data... any will suffice
}
else
{
memcpy(newbuf, buf, i*PAGE_SIZE); // copy
the contents of the old buffer to the new
}
#ifndef USE_KMALLOC
vfree(buf); // free the old buffer
#else
kfree(buf); // free the old buffer
#endif
buf = newbuf;
// print out the first few bytes
for (j=0; j < 10; j++)
{
printk("0x%02X ", 0xff & buf[j]);
}
printk("\n");
}
#ifndef USE_KMALLOC
vfree(buf);
#else
kfree(buf);
#endif
return 0;
}
module_init(vmalloctest_init);
MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 5+ messages in thread
* vmalloc memory corruption
2005-01-04 21:24 Christian Gan
@ 2005-01-04 21:24 ` Christian Gan
0 siblings, 0 replies; 5+ messages in thread
From: Christian Gan @ 2005-01-04 21:24 UTC (permalink / raw)
To: linux-mips
Hey all,
I'm running into a strange memory corruption problem while trying to get
a driver to load firmware using hotplug support on a DBAU1550 eval
board. This board has a single AU1550 MIPS32 processor. I'm running
kernel version 2.6.10-rc3.
I've attached a code snippet below that I'd like somebody to try to
verify for me so I can determine whether or not it is a problem with my
kernel/hardware.
The test code is a simplified version of the interaction between the
driver and the firmware/hotplug support of the kernel. The firmware
hotplug support (linux/drivers/base/firmware_class.c) if fed data from a
file and places it into a buffer, this buffer gets reallocated when
required and grows as more data is read in. Old data is memcopied into
the new reallocated buffer and newly read data is appended to the end.
What I'm finding is that eventually this data is corrupted.
Compile the test snippet below as a module and insmod it. If things are
successful you should see results like this:
# insmod vmalloctest.ko
Using vmalloctest.ko
testing vmalloc
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
...
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
But if data changes at any time, you've got problems like me. When I
run this on my platform eventually the data becomes all 0x00.
Notice that if you use kmalloc instead of vmalloc (define USE_KMALLOC),
everything works.
Thanks!
Christian Gan
// Start vmalloctest.c
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/vmalloc.h>
#include <asm/io.h>
//#define USE_KMALLOC
void fillbuf(char * buf, unsigned long len)
{
int i = 0;
for (i = 0; i < len; i++)
{
buf[i] = 0xFF & i;
}
}
int __init vmalloctest_init(void)
{
char * buf = NULL;
int i = 0;
printk("testing vmalloc\n");
for (i = 0; i < 50; i++)
{
int j = 0;
#ifndef USE_KMALLOC
char * newbuf = vmalloc( (i+1)*PAGE_SIZE );
// allocate a new buffer that grows in size
#else
char * newbuf = kmalloc( (i+1)*PAGE_SIZE, GFP_KERNEL );
// allocate a new buffer that grows in size
#endif
if (!newbuf)
{
printk("Could not allocate memory: %ld bytes\n",
(i+1)*PAGE_SIZE);
break;
}
if (i==0)
{
fillbuf(newbuf, PAGE_SIZE ); // fill
the original buffer with some data... any will suffice
}
else
{
memcpy(newbuf, buf, i*PAGE_SIZE); // copy
the contents of the old buffer to the new
}
#ifndef USE_KMALLOC
vfree(buf); // free the old buffer
#else
kfree(buf); // free the old buffer
#endif
buf = newbuf;
// print out the first few bytes
for (j=0; j < 10; j++)
{
printk("0x%02X ", 0xff & buf[j]);
}
printk("\n");
}
#ifndef USE_KMALLOC
vfree(buf);
#else
kfree(buf);
#endif
return 0;
}
module_init(vmalloctest_init);
MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: vmalloc memory corruption
@ 2005-01-06 20:08 Christian Gan
2005-01-06 20:08 ` Christian Gan
2005-01-06 20:11 ` Pete Popov
0 siblings, 2 replies; 5+ messages in thread
From: Christian Gan @ 2005-01-06 20:08 UTC (permalink / raw)
To: linux-mips
Just a little update on this:
I turned off 36 bit address support for the MIPS32
(CONFIG_64BIT_PHYS_ADDR) and found that my tests for vmalloc work.
Can anyone who knows better point me in a direction of where I should
start?
Thanks!
Christian
-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Christian Gan
Sent: Tuesday, January 04, 2005 3:25 PM
To: linux-mips@linux-mips.org
Subject: vmalloc memory corruption
Hey all,
I'm running into a strange memory corruption problem while trying to get
a driver to load firmware using hotplug support on a DBAU1550 eval
board. This board has a single AU1550 MIPS32 processor. I'm running
kernel version 2.6.10-rc3.
I've attached a code snippet below that I'd like somebody to try to
verify for me so I can determine whether or not it is a problem with my
kernel/hardware.
The test code is a simplified version of the interaction between the
driver and the firmware/hotplug support of the kernel. The firmware
hotplug support (linux/drivers/base/firmware_class.c) if fed data from a
file and places it into a buffer, this buffer gets reallocated when
required and grows as more data is read in. Old data is memcopied into
the new reallocated buffer and newly read data is appended to the end.
What I'm finding is that eventually this data is corrupted.
Compile the test snippet below as a module and insmod it. If things are
successful you should see results like this:
# insmod vmalloctest.ko
Using vmalloctest.ko
testing vmalloc
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
...
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
But if data changes at any time, you've got problems like me. When I
run this on my platform eventually the data becomes all 0x00.
Notice that if you use kmalloc instead of vmalloc (define USE_KMALLOC),
everything works.
Thanks!
Christian Gan
// Start vmalloctest.c
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/vmalloc.h>
#include <asm/io.h>
//#define USE_KMALLOC
void fillbuf(char * buf, unsigned long len)
{
int i = 0;
for (i = 0; i < len; i++)
{
buf[i] = 0xFF & i;
}
}
int __init vmalloctest_init(void)
{
char * buf = NULL;
int i = 0;
printk("testing vmalloc\n");
for (i = 0; i < 50; i++)
{
int j = 0;
#ifndef USE_KMALLOC
char * newbuf = vmalloc( (i+1)*PAGE_SIZE );
// allocate a new buffer that grows in size
#else
char * newbuf = kmalloc( (i+1)*PAGE_SIZE, GFP_KERNEL );
// allocate a new buffer that grows in size
#endif
if (!newbuf)
{
printk("Could not allocate memory: %ld bytes\n",
(i+1)*PAGE_SIZE);
break;
}
if (i==0)
{
fillbuf(newbuf, PAGE_SIZE ); // fill
the original buffer with some data... any will suffice
}
else
{
memcpy(newbuf, buf, i*PAGE_SIZE); // copy
the contents of the old buffer to the new
}
#ifndef USE_KMALLOC
vfree(buf); // free the old buffer
#else
kfree(buf); // free the old buffer
#endif
buf = newbuf;
// print out the first few bytes
for (j=0; j < 10; j++)
{
printk("0x%02X ", 0xff & buf[j]);
}
printk("\n");
}
#ifndef USE_KMALLOC
vfree(buf);
#else
kfree(buf);
#endif
return 0;
}
module_init(vmalloctest_init);
MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: vmalloc memory corruption
2005-01-06 20:08 vmalloc memory corruption Christian Gan
@ 2005-01-06 20:08 ` Christian Gan
2005-01-06 20:11 ` Pete Popov
1 sibling, 0 replies; 5+ messages in thread
From: Christian Gan @ 2005-01-06 20:08 UTC (permalink / raw)
To: linux-mips
Just a little update on this:
I turned off 36 bit address support for the MIPS32
(CONFIG_64BIT_PHYS_ADDR) and found that my tests for vmalloc work.
Can anyone who knows better point me in a direction of where I should
start?
Thanks!
Christian
-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Christian Gan
Sent: Tuesday, January 04, 2005 3:25 PM
To: linux-mips@linux-mips.org
Subject: vmalloc memory corruption
Hey all,
I'm running into a strange memory corruption problem while trying to get
a driver to load firmware using hotplug support on a DBAU1550 eval
board. This board has a single AU1550 MIPS32 processor. I'm running
kernel version 2.6.10-rc3.
I've attached a code snippet below that I'd like somebody to try to
verify for me so I can determine whether or not it is a problem with my
kernel/hardware.
The test code is a simplified version of the interaction between the
driver and the firmware/hotplug support of the kernel. The firmware
hotplug support (linux/drivers/base/firmware_class.c) if fed data from a
file and places it into a buffer, this buffer gets reallocated when
required and grows as more data is read in. Old data is memcopied into
the new reallocated buffer and newly read data is appended to the end.
What I'm finding is that eventually this data is corrupted.
Compile the test snippet below as a module and insmod it. If things are
successful you should see results like this:
# insmod vmalloctest.ko
Using vmalloctest.ko
testing vmalloc
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
...
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
But if data changes at any time, you've got problems like me. When I
run this on my platform eventually the data becomes all 0x00.
Notice that if you use kmalloc instead of vmalloc (define USE_KMALLOC),
everything works.
Thanks!
Christian Gan
// Start vmalloctest.c
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/vmalloc.h>
#include <asm/io.h>
//#define USE_KMALLOC
void fillbuf(char * buf, unsigned long len)
{
int i = 0;
for (i = 0; i < len; i++)
{
buf[i] = 0xFF & i;
}
}
int __init vmalloctest_init(void)
{
char * buf = NULL;
int i = 0;
printk("testing vmalloc\n");
for (i = 0; i < 50; i++)
{
int j = 0;
#ifndef USE_KMALLOC
char * newbuf = vmalloc( (i+1)*PAGE_SIZE );
// allocate a new buffer that grows in size
#else
char * newbuf = kmalloc( (i+1)*PAGE_SIZE, GFP_KERNEL );
// allocate a new buffer that grows in size
#endif
if (!newbuf)
{
printk("Could not allocate memory: %ld bytes\n",
(i+1)*PAGE_SIZE);
break;
}
if (i==0)
{
fillbuf(newbuf, PAGE_SIZE ); // fill
the original buffer with some data... any will suffice
}
else
{
memcpy(newbuf, buf, i*PAGE_SIZE); // copy
the contents of the old buffer to the new
}
#ifndef USE_KMALLOC
vfree(buf); // free the old buffer
#else
kfree(buf); // free the old buffer
#endif
buf = newbuf;
// print out the first few bytes
for (j=0; j < 10; j++)
{
printk("0x%02X ", 0xff & buf[j]);
}
printk("\n");
}
#ifndef USE_KMALLOC
vfree(buf);
#else
kfree(buf);
#endif
return 0;
}
module_init(vmalloctest_init);
MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: vmalloc memory corruption
2005-01-06 20:08 vmalloc memory corruption Christian Gan
2005-01-06 20:08 ` Christian Gan
@ 2005-01-06 20:11 ` Pete Popov
1 sibling, 0 replies; 5+ messages in thread
From: Pete Popov @ 2005-01-06 20:11 UTC (permalink / raw)
To: Christian Gan; +Cc: linux-mips
Christian Gan wrote:
> Just a little update on this:
>
> I turned off 36 bit address support for the MIPS32
> (CONFIG_64BIT_PHYS_ADDR) and found that my tests for vmalloc work.
>
> Can anyone who knows better point me in a direction of where I should
> start?
Hmmm. I'll take a look at this.
Pete
>
> Thanks!
>
> Christian
>
> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Christian Gan
> Sent: Tuesday, January 04, 2005 3:25 PM
> To: linux-mips@linux-mips.org
> Subject: vmalloc memory corruption
>
> Hey all,
>
> I'm running into a strange memory corruption problem while trying to get
> a driver to load firmware using hotplug support on a DBAU1550 eval
> board. This board has a single AU1550 MIPS32 processor. I'm running
> kernel version 2.6.10-rc3.
>
> I've attached a code snippet below that I'd like somebody to try to
> verify for me so I can determine whether or not it is a problem with my
> kernel/hardware.
>
> The test code is a simplified version of the interaction between the
> driver and the firmware/hotplug support of the kernel. The firmware
> hotplug support (linux/drivers/base/firmware_class.c) if fed data from a
> file and places it into a buffer, this buffer gets reallocated when
> required and grows as more data is read in. Old data is memcopied into
> the new reallocated buffer and newly read data is appended to the end.
> What I'm finding is that eventually this data is corrupted.
>
> Compile the test snippet below as a module and insmod it. If things are
> successful you should see results like this:
>
> # insmod vmalloctest.ko
> Using vmalloctest.ko
> testing vmalloc
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
> ...
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
>
> But if data changes at any time, you've got problems like me. When I
> run this on my platform eventually the data becomes all 0x00.
>
> Notice that if you use kmalloc instead of vmalloc (define USE_KMALLOC),
> everything works.
>
> Thanks!
>
> Christian Gan
>
> // Start vmalloctest.c
>
> #ifndef __KERNEL__
> #define __KERNEL__
> #endif
>
> #include <linux/config.h>
> #include <linux/version.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/errno.h>
> #include <linux/string.h>
> #include <linux/mm.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/vmalloc.h>
>
> #include <asm/io.h>
>
> //#define USE_KMALLOC
>
> void fillbuf(char * buf, unsigned long len)
> {
> int i = 0;
> for (i = 0; i < len; i++)
> {
> buf[i] = 0xFF & i;
> }
> }
>
> int __init vmalloctest_init(void)
> {
> char * buf = NULL;
> int i = 0;
>
> printk("testing vmalloc\n");
>
> for (i = 0; i < 50; i++)
> {
> int j = 0;
> #ifndef USE_KMALLOC
> char * newbuf = vmalloc( (i+1)*PAGE_SIZE );
> // allocate a new buffer that grows in size
> #else
> char * newbuf = kmalloc( (i+1)*PAGE_SIZE, GFP_KERNEL );
> // allocate a new buffer that grows in size
> #endif
> if (!newbuf)
> {
> printk("Could not allocate memory: %ld bytes\n",
> (i+1)*PAGE_SIZE);
> break;
> }
>
> if (i==0)
> {
> fillbuf(newbuf, PAGE_SIZE ); // fill
> the original buffer with some data... any will suffice
> }
> else
> {
> memcpy(newbuf, buf, i*PAGE_SIZE); // copy
> the contents of the old buffer to the new
> }
>
> #ifndef USE_KMALLOC
> vfree(buf); // free the old buffer
> #else
> kfree(buf); // free the old buffer
> #endif
>
> buf = newbuf;
>
> // print out the first few bytes
> for (j=0; j < 10; j++)
> {
> printk("0x%02X ", 0xff & buf[j]);
> }
> printk("\n");
> }
>
> #ifndef USE_KMALLOC
> vfree(buf);
> #else
> kfree(buf);
> #endif
>
> return 0;
> }
> module_init(vmalloctest_init);
>
> MODULE_LICENSE("GPL");
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-01-06 20:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-06 20:08 vmalloc memory corruption Christian Gan
2005-01-06 20:08 ` Christian Gan
2005-01-06 20:11 ` Pete Popov
-- strict thread matches above, loose matches on Subject: below --
2005-01-04 21:24 Christian Gan
2005-01-04 21:24 ` Christian Gan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox