Hello, all.
When creating class hieararchy deeper then level 2, I've got oops...
Situation gets place, when memrc is turned on.
The bug is reproducable. You can see oops below.
I investigated the reason and here is my resolution:
in mem_res_alloc() function:
.....
pres = ckrm_memclass(parent);
if (pres && (pres->hier == CKRM_MEM_MAX_HIERARCHY)) {
printk(KERN_ERR "MEM_RC: only allows hieararchy of %d\n",
CKRM_MEM_MAX_HIERARCHY);
return NULL;
}
.....
res->hier = pres->hier + 1; <----- ooops
....
But pres pointer can be NULL!
It happens, then first, we don't create ckrm_mem_res, due to pres->hier
== CKRM_MEM_MAX_HIERARCHY, but
ckrm_class is created however (and it has to be so - other resource
controllers support more deep hiererchy).
Next time, we create class on deeper level - pres is NULL, but it isn't
checked.
Here is example:
dhcp0-138 vass # cd /config/
dhcp0-138 config # ls
ckrm
dhcp0-138 config # cd ckrm/
dhcp0-138 ckrm # ls
attrib config members shares stats
dhcp0-138 ckrm # mkdir 0
dhcp0-138 ckrm # cd 0
dhcp0-138 0 # mkdir 1
dhcp0-138 0 # cd 1
dhcp0-138 1 # mkdir 1
dhcp0-138 1 # cd 1
dhcp0-138 1 # mkdir 1
Segmentation fault
dhcp0-138 1 #
MEM_RC: only allows hieararchy of 2
Error creating mem resource class for class 0/1/1
Unable to handle kernel NULL pointer dereference at virtual address 00000044
printing eip:
c0144ce7
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU: 0
EIP: 0060:[<c0144ce7>] Not tainted VLI
EFLAGS: 00210286 (2.6.14ckrm-f0.4-cpu0.3-memrc)
EIP is at mem_res_alloc+0xd7/0x310
eax: 00000000 ebx: 00000000 ecx: f14dfc80 edx: f7d164a4
esi: f7120700 edi: 00000020 ebp: c1baae80 esp: f1f7be74
ds: 007b es: 007b ss: 0068
Process mkdir (pid: 6880, threadinfo=f1f7a000 task=f22eda70)
Stack: f14dfcac 00000020 f14dfd80 c0144191 f14dfd80 f14dfc80 00000002
f7120500
00000003 f7d1e680 c0141949 f7120500 f7120700 ffffffff f7120500
f7120700
c0141a78 f7120500 f7120700 00000002 f7155700 f7120580 f7155602
f7d1e680
Call Trace:
[<c0144191>] cpu_res_alloc+0x51/0xb0
[<c0141949>] ckrm_alloc_res_class+0x79/0xb0
[<c0141a78>] ckrm_alloc_class+0xf8/0x120
[<c021074e>] taskclass_make_group+0xfe/0x170
[<c020ece1>] configfs_mkdir+0x121/0x310
[<c0176b6f>] permission+0x6f/0xa0
[<c0179464>] vfs_mkdir+0x74/0xf0
[<c0179586>] sys_mkdir+0xa6/0xf0
[<c0167559>] sys_close+0x69/0x80
[<c0103135>] syscall_call+0x7/0xb
Code: 83 c0 24 89 42 04 8b 4c 24 14 c7 40 04 c0 d9 47 c0 89 51 24 a3 c0
d9 47 c0 b8 b0 3a 54 c0 e8 61 78 2b 00 85 f6 0f 84 94 01 00 00 <8b> 43
44 8b 54 24 14 40 89 42 44 89 1c 24 e8 16 fd ff ff 83 7b
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
