From: Bencsath Boldizsar <boldi@datacontact.hu>
Subject: some more info
Date: Sat, 24 Mar 2001 01:59:09 +0100 (CET)
Next Article (by Date): RSBAC v1.1.1 problem Keith Matthews
Previous Article (by Date): Re: kernel hang242 Amon Ott
Articles sorted by: [Date]
[Author]
[Subject]
So if I don't change the kmalloces to vmalloces then the kmalloc hangs, if
I change it (even on 1.1.1) , it hangs at the write lock where the Item
Not for this list is processed.
root@db:/usr/src/linux/rsbac# ls -la /rsbac
total 40
drwx------ 2 root root 4096 Mar 21 12:16 .
drwxr-xr-x 27 root root 4096 Mar 21 11:47 ..
-rw------- 1 root root 76 Mar 21 11:47 fd_aci.15
-rw------- 1 root root 4 Mar 21 12:16 fd_aci.18
-rw------- 1 root root 76 Mar 21 11:50 fd_aci.22
-rw------- 1 root root 76 Mar 21 11:47 fd_aci.25
-rw------- 1 root root 76 Mar 21 11:47 fd_aci.28
-rw------- 1 root root 76 Mar 21 12:16 fd_aci.29
-rw------- 1 root root 148 Mar 21 11:50 fd_aci.7
-rw------- 1 root root 76 Mar 21 11:47 fd_aci.7b
the problem is with the aci 29:
root@db:/usr/src/linux/rsbac# hexdump /rsbac/fd_aci.29
0000000 0004 0000 65a8 0004 00fd 0000 fffd ffff
0000010 0001 0000 0000 0000 0301 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0100
0000030 4200 0000 ffff ffff ffff ffff ffff ffff
0000040 ffff ffff 0000 0000 0000 0000
000004c
boldi@eternal:~$ perl -e ' print 288168 % 30;'
18
boldi@eternal:~$ perl -e 'print "$i",0x0465a8'
288168
The inode itself points to /rsbac.
Background: I used kernel 2.2.18, emergency mode and about pre4 or
so. Then last time I created /bin/sh and some other program modifications,
so next time I would be able the use a not emergency kernel too. After
that I booted 2.4.2+pre7. It hangs. 2.2.18 with emergency mode hangs too.
So somehow the /rsbac dir was not created right, it hasn't been added to
fd_aci.18 but to fd_aci.29.
The other problem that fd.aci.18 is only 4 bytes long.
root@db:/usr/src/linux/rsbac# hexdump /rsbac/fd_aci.18
0000000 0004 0000
0000004
Is it right? Should be deleted? But anyhow, why does the write_lock oops.
At last, here is the ksymboops from the last hang with 2.4.2 separate
thread 1.1.1 + vmalloces.
Unable to handle kernel paging request at virtual address d0eb27d4
printing eip:
c01b2ce9
*pde = 00000000
rOops: 0002
CPU0
EIP: 0010:[<c01b2ce9>]
EFLAGS: 00010082
eax: d0eb27d4 ebx: d0eb27c8 ecx: d0822000 edx: d081a000
esi: 000465a8 edi: d081c00a ebp: cfecbf18 esp: cfecbe34
ds: 0018 es: 0018 ss: 0018
Process rsbac_initd (pid: 16, stackpage=cfecb000)
Stack: c03dd420 c0306199 cfecbf68 00000001 00000009 0000001e cfecbeb8
cfecbeb0
00000900 00000009 00090000 00000000 00007a00 00000009 00000000
cfeca000
00000000 ffffffff d081e000 d0820000 d0822000 d081a2c0 00000006
00000000
Call Trace: [<d081e000>] [<d0820000>] [<d0822000>] [<d081a2c0>]
[<d081c000>] [<d081a000>
] [<d081a000>]
[<c010a8d5>] [<c010900c>] [<c0115d46>] [<c01b743c>] [<c01b74a9>]
[<c01074c4>]
Code: f0 81 28 00 00 00 01 0f 85 31 80 11 00 0f b7 b5 4e ff ff ff c01b2ce9
*pde = 00000000
EIP: 0010:[<c01b2ce9>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: d0eb27d4 ebx: d0eb27c8 ecx: d0822000 edx: d081a000
esi: 000465a8 edi: d081c00a ebp: cfecbf18 esp: cfecbe34
ds: 0018 es: 0018 ss: 0018
Process rsbac_initd (pid: 16, stackpage=cfecb000)
Stack: c03dd420 c0306199 cfecbf68 00000001 00000009 0000001e cfecbeb8
cfecbeb0
00000900 00000009 00090000 00000000 00007a00 00000009 00000000
cfeca000
00000000 ffffffff d081e000 d0820000 d0822000 d081a2c0 00000006
00000000
Call Trace: [<d081e000>] [<d0820000>] [<d0822000>] [<d081a2c0>]
[<d081c000>] [<d081a000>
[<c010a8d5>] [<c010900c>] [<c0115d46>] [<c01b743c>] [<c01b74a9>]
[<c01074c4>]
Code: f0 81 28 00 00 00 01 0f 85 31 80 11 00 0f b7 b5 4e ff ff ff
>>EIP; c01b2ce9 <read_fd_lists+671/998> <=====
Trace; d081e000 <END_OF_CODE+103e050c/????>
Trace; d0820000 <END_OF_CODE+103e250c/????>
Trace; d0822000 <END_OF_CODE+103e450c/????>
Trace; d081a2c0 <END_OF_CODE+103dc7cc/????>
Trace; d081c000 <END_OF_CODE+103de50c/????>
Trace; d081a000 <END_OF_CODE+103dc50c/????>
Trace; c010a8d5 <do_IRQ+e5/f4>
Trace; c010900c <ret_from_intr+0/20>
Trace; c0115d46 <printk+16e/17c>
Trace; c01b743c <rsbac_initd+c/e4>
Trace; c01b74a9 <rsbac_initd+79/e4>
Trace; c01074c4 <kernel_thread+28/38>
Code; c01b2ce9 <read_fd_lists+671/998>
00000000 <_EIP>:
Code; c01b2ce9 <read_fd_lists+671/998> <=====
0: f0 81 28 00 00 00 01 lock subl $0x1000000,(%eax) <=====
Code; c01b2cf0 <read_fd_lists+678/998>
7: 0f 85 31 80 11 00 jne 11803e <_EIP+0x11803e> c02cad27
<stext_lock+3aaf/8433>
Code; c01b2cf6 <read_fd_lists+67e/998>
d: 0f b7 b5 4e ff ff ff movzwl 0xffffff4e(%ebp),%esi
for beginners: install ksymoops package, save the kernel panic output (the
best method is serial console logging), then run ksymoops with the right
specification of the System.map file.
To install serial console, get a serial cable. connect two computers. On
one use minicom or something to save output. On the other compile the
kernel with serial console support.
then add serial = 1,38400 to the global part of the lilo.conf (1 for
ttyS1) put append="console=ttyS1,38400n8 console=tty0" for the kernel
definiton part. lilo. At the next boot it shoudl print the messages.
To check what is the inode name of an inode number, install e2fsprogs,
run debugfs. Enter open /dev/hda5 or anything you like. then enter
ncheck 12354 (where the number is the inode number).
to get info about what's going in the rsbac the best way is to put some
debug messages to
/usr/src/linux/rsbac/data_structures/aci_data_structures.c
like
rsbac_write_lock(&tmp_head_p->lock, &flags);
printk(KERN_WARNING
"after write lock not ok id %lu on list%i,device %02u:%02u\n",
fd_aci_p->id, i, MAJOR(kdev), MINOR(kdev));
last comment: I can't run rsbac_check, because rsbac is not initialized or
not loaded at all. If I could run it that could lead to a solution. or
not?
--------------------------------
Bencsath Boldizsar
boldi@etl.hu
--------------------------------
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.
Next Article (by Date): RSBAC v1.1.1 problem Keith Matthews
Previous Article (by Date): Re: kernel hang242 Amon Ott
Articles sorted by: [Date]
[Author]
[Subject]