On Sun, Mar 8, 2009 at 1:00 PM, yogeshwar sonawane <yogyas@xxxxxxxxx> wrote:
> Thank daniel.
>
> How to know such limit ? some kernel info is available ?
>
The kernel stack size is set at compile time , using some config variables.
> 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.
>
I think that kernel stack size is setup to 8K for the nodes where
all works fine and 4K for the nodes where you get the panic.
> 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
