you can use readelf to dump out the elf information of your .ko
Where do static variables get stored? Definitely not in the stack. Hence your observation.
- durga
From: yogeshwar sonawane <yogyas@xxxxxxxxx>
To: kernelnewbies <kernelnewbies@xxxxxxxxxxxx>
Sent: Monday, March 9, 2009 3:36:19 PM
Subject: Re: array declaration inside init function causing kernel panic
Hi,
Continuing my discussion, i tried one more thing.
I changed my array declaration from unsigned int array[] to static
unsigned int array[].
Then the kernel panic has disappeared. Now things are working fine.
For ELF file format, one is aware of the different section like code,bss etc....
Similarly, what are the sections for driver module ?
Can one dump more information using some command on a .ko object ?
(like in my case, where array is placed ? in data or stack ?)
TIA,
Yogeshwar
On Sun, Mar 8, 2009 at 4:53 PM, Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote:
> 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
