Thank daniel.
How to know such limit ? some kernel info is available ?
As i mentioned in my mail, i am using 2.6.9-42.ELsmp kernel
(RHEL4-update 4,x86_64) on intel platform.
Other intel node with RHEL4-update 5(2.6.9-55.ELlargesmp) gave same
kernel panic with same code.
But when i tried the same code in RHEL-5.1 (2.6.18-53.el5) & RHEL-5.2
(2.6.18-92.el5) on third intel node,
the things were working as normal, without kernel panic.
But on one amd node, using CentOS-5.1 (2.6.18-53.el5), i got the kernel panic.
These are just my observations. But, nothing concrete is coming out
apart from the fact that kernel stack is getting corrupted.
Is it machine/platform/memory size dependent ? or some other factors
are also important ?
TIA,
Yogeshwar
On Sun, Mar 8, 2009 at 3:44 PM, Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote:
> Hello ,
>
> When you are declaring a variable inside a function it is pushed onto the stack.
> The kernel stack is small , 4K so i guess that you somehow corrupt the stack.
>
> thanks,
> Daniel.
>
> On Sun, Mar 8, 2009 at 11:55 AM, yogeshwar sonawane <yogyas@xxxxxxxxx> wrote:
>> Hi,
>>
>> While doing some driver development, i was seeing a kernel panic.
>> After some trials, i found a simple condition which is triggering that
>> kernel panic.
>>
>> I have declared an array having large interger elements(@2k) in
>> init_module(). The values are random/dummy.
>> The driver is a very simple code, just registering a character driver
>> in init_module() &
>> unregistering in cleanup_module() functions respectively.
>>
>> After clean compilation, when i try to load my module, i see kernel
>> panic message(pasted below).
>> But, if i declare that array as a global variable(outside any
>> function), then it works fine. No any panic seen.
>>
>> I tried putting the array in cleanup_module(), then also panic is
>> seen, but with some different messages.
>> I tried some different values in array, then also panic seen, but
>> messages are different.
>> my guess is that some corruption is happening inside kernel.
>>
>> I just want to understand the reason behind this.
>> Is there any limit for local variables while writing drivers ?
>> How to know such limits ?
>>
>> Kindly update me, if i am missing something very basic.
>> Any info/link/reference will be helpful.
>>
>> For normal user processes, such large array declarations in a function
>> OR outside the function, does not create any problem.
>>
>> I am using 2.6.9-42.ELsmp kernel (RHEL4-update 4,x86_64).
>>
>> driver.c & Makefile are attached with this mail.
>>
>> # insmod driver.ko
>> In init modulesize of array = 8992
>> The device is registered by Major no: 253
>> Unable to handle kernel NULL pointer dereference at 0000000000000048 RIP:
>> <ffffffff80139fa7>{do_exit+1027}
>> PML4 13364e067 PGD 0
>> Oops: 0000 [1] SMP
>> CPU 0
>> Modules linked in: driver(U) autofs4 i2c_dev i2c_core nfs lockd
>> nfs_acl sunrpc rdma_ucm(U) ib_sdp(U) rdma_cm(U) d
>> Pid: 4626, comm: insmod Not tainted 2.6.9-42.ELsmp
>> RIP: 0010:[<ffffffff80139fa7>] <ffffffff80139fa7>{do_exit+1027}
>> RSP: 0018:0000010133685f08 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: 0000010037c56780 RCX: 0000000000000014
>> RDX: 0000000000000056 RSI: 0000010001043380 RDI: 0000000000000000
>> RBP: 0000010037f08f40 R08: 0000010001043380 R09: 0000010001043380
>> R10: 0000000000000000 R11: 0000010037c56780 R12: 0000010037c56030
>> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000502010
>> FS: 0000000000000000(0000) GS:ffffffff804e5080(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 0000000000000048 CR3: 0000000000101000 CR4: 00000000000006e0
>> Process insmod (pid: 4626, threadinfo 0000010133684000, task 0000010037c56030)
>> Stack: d42e0180a6fb127c a643177c00000060 ffff0038d82e41b8 0000000000000000
>> 0000003556c2b110 0000003556c2b110 0000000000000000 0000000000000000
>> 0000007fbffff8f0 0000000000502030
>> Call Trace:<ffffffff8013a8f6>{sys_exit_group+0}
>> <ffffffff8011026a>{system_call+126}
>>
>>
>> Code: 48 8b 50 48 48 85 d2 74 29 65 8b 04 25 34 00 00 00 89 c0 48
>> RIP <ffffffff80139fa7>{do_exit+1027} RSP <0000010133685f08>
>> CR2: 0000000000000048
>> <0>Kernel panic - not syncing: Oops
>>
>>
>> Thanks,
>> Yogeshwar
>>
>>
>> Note:- Earlier i tried to send the same mail with driver.c & Makefile
>> as attachments, but i think kernelnewbies mailing list does not accept
>> mails with attachments. Correct me, if i am wrong ? Now, i am pasting
>> the codes below.
>>
>> driver.c :-
>>
>> #include <linux/module.h>
>> #include <linux/kernel.h>
>> #include <linux/fs.h>
>>
>> struct file_operations fops;
>> static int major;
>>
>> int mydevice_init_module(void)
>> {
>> unsigned int array[] = {
>> 0x00000000, 0x00000000, 0x00000000, 0x00000000,
>> 0x12345678, 0x12345678, 0x12345678, 0x12345678,
>> ......set any dummy/garbage values, .......................
>> ................create large sized array..........................
>> } ;
>>
>> printk("In init module");
>> printk("size of array = %ld\n", sizeof(array)) ;
>> major = register_chrdev(0,"mydevice",&fops);
>> printk("\nThe device is registered by Major no: %d",major);
>> if(major == -1)
>> printk("\nError in registering the module");
>> else
>> printk("\n");
>> return 0;
>> }
>>
>> void mydevice_cleanup_module(void)
>> {
>> unregister_chrdev(major,"mydevice");
>> printk("In cleanup module");
>> }
>>
>> static int my_open(struct inode *inode, struct file *file)
>> {
>> printk("\nmydevice: open");
>> return 0;
>> }
>>
>> static int my_release(struct inode *inode, struct file *file)
>> {
>> printk("\nmydevice: release");
>> return 0;
>> }
>>
>> struct file_operations fops =
>> {
>> open: my_open,
>> release: my_release,
>> };
>>
>> module_init(mydevice_init_module);
>> module_exit(mydevice_cleanup_module);
>> MODULE_LICENSE("GPL");
>>
>>
>> Makefile :-
>>
>> obj-m := driver.o
>> KDIR := /lib/modules/$(shell uname -r)/build
>> PWD := $(shell pwd)
>> EXTRA_CFLAGS += -D DEBUG_INFO -D DEBUG_CRITICAL
>>
>> default :
>> $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
>>
>> clean :
>> $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
