#113 exit totem sometimes panic in ssi_semexit

[Anonymous]

When exiting totem sometimes the system will panic in
ssi_semexit.

Debian Sid with 1.9.2ish kernel.

Unable to handle kernel NULL pointer dereference at
virtual address 00000004
printing eip:
c01d4b6d
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: radeon button ac battery parport_pc
parport pcspkr snd_intel8x0 snd_ac97_codec snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd soundcore
snd_page_alloc i2c_i801 i2c_core ata_piix libata
hw_random ehci_hcd uhci_hcd sd_mod aic7xxx scsi_mod tg3
e1000
CPU: 1
EIP: 0060:[<c01d4b6d>] Not tainted VLI
EFLAGS: 00210246 (2.6.10-ssi-1.9.2-jh-3)
EIP is at ssi_semexit+0x3d/0xd0
eax: f5005188 ebx: 00060b37 ecx: 00000000 edx:
f665d2c0
esi: f5005188 edi: f6b48b80 ebp: f6d5fdcc esp:
f6d5fdb0
ds: 007b es: 007b ss: 0068
Process totem (pid: 396087, threadinfo=f6d5f000
task=f7e21250)
Stack: c0732040 00070000 f6d5fdd8 c0153177 00070000
f6d5f000 f6b48b80 f6d5fe5c
c01d474e 00070000 00060b37 c015dc88 0000005d
f720c660 00000000 f6d5fe0c
f6b48bcc f6b48bc0 f720c660 f6c4dc58 00000006
f720c660 f580ac80 f6d5fe48
Call Trace:
[<c010671f>] show_stack+0x7f/0xa0
[<c01068c4>] show_registers+0x164/0x230
[<c0106c74>] die+0xf4/0x1c0
[<c011f56d>] do_page_fault+0x48d/0x689
[<c0106383>] error_code+0x2b/0x30
[<c01d474e>] exit_sem+0x15e/0x190
[<c012a619>] do_exit+0x159/0x4f0
[<c012aa7a>] do_group_exit+0x3a/0xc0
[<c0135163>] get_signal_to_deliver+0x233/0x360
[<c0105590>] do_signal+0x70/0x150
[<c01056c7>] do_notify_resume+0x57/0x8c
[<c0105866>] work_notifysig+0x13/0x15
Code: c0 8b 5d 0c 89 44 24 04 e8 a1 a8 ff ff 85 c0 89
c6 74 33 8b 48 44 8d 50 44 eb 0c 8d 76 00 39 59 04 74
2b 89 ca 8b 09 85 c9 75 f3 <8b> 41 04 c7 04 24 a8 14 49
c0 89 44 24 04 e8 50 36 f5 ff 89 34

Entering kdb (current=0xf7e21250, pid 396087) on
processor 1 Oops: Oops
due to oops @ 0xc01d4b6d
eax = 0xf5005188 ebx = 0x00060b37 ecx = 0x00000000 edx
= 0xf665d2c0
esi = 0xf5005188 edi = 0xf6b48b80 esp = 0xf6d5fdb0 eip
= 0xc01d4b6d
ebp = 0xf6d5fdcc xss = 0xc03a0068 xcs = 0x00000060
eflags = 0x00210246
xds = 0xf665007b xes = 0x0000007b origeax = 0xffffffff
&regs = 0xf6d5fd7c
[1]kdb>
Stack traceback for pid 396087
0xf7e21250 396087 1 1 1 R 0xf7e21430 *totem
EBP EIP Function (args)
0xf6d5fdcc 0xc01d4b6d ssi_semexit+0x3d (0x70000,
0x60b37, 0xc015dc88, 0x5d, 0xf720c660)
0xf6d5fe5c 0xc01d474e exit_sem+0x15e (0xf7e21250, 0x2b,
0x1, 0xf68b2c84, 0xf7e21718)
0xf6d5fe8c 0xc012a619 do_exit+0x159 (0x0, 0x0, 0x0,
0x9, 0xf6d5f000)
0xf6d5feac 0xc012aa7a do_group_exit+0x3a (0x9, 0x0,
0x0, 0xf6d5f000, 0xf6d5f000)0xf6d5fedc 0xc0135163
get_signal_to_deliver+0x233 (0xf6d5ff18, 0xf6d5fef8,
0xf6d5ffc4, 0x0, 0x200282)
0xf6d5ffa4 0xc0105590 do_signal+0x70 (0xf7214580,
0x8297010, 0x8297010, 0xb71e37b0)
0xf6d5ffbc 0xc01056c7 do_notify_resume+0x57
0xc0105866 work_notifysig+0x13
[1]kdb>

[Roger Tsang]

[Roger Tsang]

Logged In: YES
user_id=1246761

It seems OpenSSI-1.9 doesn't do sem_checkid() in
ssi_semexit(). Try the following patch.

[John Hughes]

Logged In: YES
user_id=166336

In the patch I see:

+/* ROGER from OPENSSI-FC-1-2 */
+ if (sem_checkid(sma,semid)) {
+ sem_unlock(semid);
+ return;
+ }
+

Surely that should be "sem_unlock(sma)"?

[John Hughes]

Logged In: YES
user_id=166336

Well, the patch doesn't help.

Stack traceback for pid 396068
0xf7c1b3d0 396068 1 1 1 R 0xf7c1b5b0 *totem
EBP EIP Function (args)
0xf7f31dcc 0xc01d4bb2 ssi_semexit+0x52 (0xc0000, 0x60b24,
0xc015dc88, 0x5d, 0xf77ad1c8)

Doing an objdump on ssi_semexit.c I see that
ssi_semexit+0x52 is

ipc/sem.c:2192
2b32: 8b 41 04 mov 0x4(%ecx),%eax
2b35: c7 04 24 14 01 00 00 movl $0x114,(%esp)
2b3c: 89 44 24 04 mov %eax,0x4(%esp)
2b40: e8 fc ff ff ff call 2b41
<ssi_semexit+0x61>

And that around line 2192 of sem.c is:

for (unp = &sma->undo; (un = *unp); unp =
&un->id_next) {
if (pid == un->pid)
goto found;
}
printk ("sem_exit undo list error id=%d\n", un->pid);

Hang on a second, if it falls out of that loop we know that
"un" is 0 and it immediately tries to use un->pid. Bad!

I've hacked the message to print just "pid" instead of
"un->pid", testing now.

[Nobody/Anonymous]

Logged In: NO

Ok, changing "un->pid" to just "pid" in the printk call
"fixes" this bug. I guess something is still wrong, but at
least the system doesn't crash.

[Roger Tsang]

Logged In: YES
user_id=1246761

Yup un->pid matches the oops report. Also looking into
whether we want kfree(un) after goto found in ssi_semexit()...

[Roger Tsang]

Logged In: YES
user_id=1246761

I've created this newer patch (attached) and tested for a
little over a week now. This code going into CVS end of
week if no further comments.

[Roger Tsang]

fix panic and possible memory corruption