Bug#444981: linux-image-2.6.18-4-686: Oops in free_uid()

[Lars Bohn]

Package: linux-image-2.6.18-6-686-bigmem
Version: 2.6.18.dfsg.1-18etch1

Here are the next kernel panic from week before last :

May  9 13:11:20 server kernel: BUG: unable to handle kernel paging request at 
virtual address 00100104
May  9 13:11:20 server kernel:  printing eip:
May  9 13:11:20 server kernel: c01260ba
May  9 13:11:20 server kernel: *pde = 07712001
May  9 13:11:20 server kernel: *pte = 00000000
May  9 13:11:20 server kernel: Oops: 0002 [#1]
May  9 13:11:20 server kernel: SMP
May  9 13:11:20 server kernel: Modules linked in: ipt_REJECT xt_tcpudp 
iptable_filter ip_tables x_tables nfs nfsd exportfs lockd nfs_acl sunrpc ipv6 
xfs dm_snapshot dm_mirror dm_mod ipmi_devintf ipmi_si ipmi_msghandler 
ide_generic ide_disk parport_pc i2c_i801 serio_raw shpMay  9 13:11:20 server 
kernel: CPU:    3
May  9 13:11:20 server kernel: EIP:    0060:[<c01260ba>]    Not tainted VLI
May  9 13:11:20 server kernel: EFLAGS: 00010002   (2.6.18-6-686-bigmem #1)
May  9 13:11:20 server kernel: EIP is at free_uid+0x22/0x64
May  9 13:11:20 server kernel: eax: 00200200   ebx: c53caa00   ecx: c53caa28   
edx: 00100100
May  9 13:11:20 server kernel: esi: 00000086   edi: e3f11f34   ebp: d8e8e748   
esp: e3f11e84
May  9 13:11:20 server kernel: ds: 007b   es: 007b   ss: 0068
May  9 13:11:20 server kernel: Process smbd (pid: 20029, ti=e3f10000 
task=e80ea000 task.ti=e3f10000)
May  9 13:11:20 server kernel: Stack: d8e8e748 d8e8e774 c012653d f718a218 
c012691f 0000000a 0000000a 00000009
May  9 13:11:20 server kernel:        00000000 00000000 e3f11f14 e80ea000 
e80ea464 c0127b51 00000000 00000021
May  9 13:11:20 server kernel:        b7d54ff4 e3f11fbc c0127ecb e3f11fbc 
e3f11f94 e3f11f14 e80ea464 00000003
May  9 13:11:20 server kernel: Call Trace:
May  9 13:11:20 server kernel:  [<c012653d>] __sigqueue_free+0x1e/0x2d
May  9 13:11:20 server kernel:  [<c012691f>] __dequeue_signal+0x108/0x15c
May  9 13:11:20 server kernel:  [<c0127b51>] dequeue_signal+0x2d/0x9c
May  9 13:11:20 server kernel:  [<c0127ecb>] get_signal_to_deliver+0xe3/0x3bc
May  9 13:11:20 server kernel:  [<c01023a2>] do_notify_resume+0x71/0x5d7
May  9 13:11:20 server kernel:  [<c01166f5>] __wake_up_common+0x2f/0x53
May  9 13:11:20 server kernel:  [<c027f582>] schedule+0x84e/0x8fe
May  9 13:11:20 server kernel:  [<c012ab09>] sys_setresuid+0x1ae/0x1c0
May  9 13:11:20 server kernel:  [<c0102d06>] work_notifysig+0x13/0x19
May  9 13:11:20 server kernel: Code: 30 c0 56 9d 5b 31 c0 5e c3 56 85 c0 53 89 
c3 74 59 9c 5e fa ba d4 be 2c c0 e8 53 0d 09 00 85 c0 74 46 8d 4b 28 8b 53 28 
8b 41 04 <89> 42 04 89 10 89 f2 b8 d4 be 2c c0 c7 41 04 00 02 20 00 c7 43
May  9 13:11:20 server kernel: EIP: [<c01260ba>] free_uid+0x22/0x64 SS:ESP 
0068:e3f11e84

After this kernel panic, I installed my own debian kernel package. I build it 
with the current debian kernel sources and a patched kernel/user.c

Here are the diff for the patched file kernel/user.c

--- user.c      2006-09-20 05:42:06.000000000 +0200
+++ user.c      2008-05-09 10:26:24.000000000 +0200
@@ -187,6 +187,17 @@
        atomic_dec(&old_user->processes);
        switch_uid_keyring(new_user);
        current->user = new_user;
+
+       /*
+        * We need to synchronize with __sigqueue_alloc()
+        * doing a get_uid(p->user).. If that saw the old
+        * user value, we need to wait until it has exited
+        * its critical region before we can free the old
+        * structure.
+        */
+       smp_mb();
+       spin_unlock_wait(&current->sighand->siglock);
+
        free_uid(old_user);
        suid_keys(current);
 }

We also identified the users, which are the cause for kernel panic and 
stressing access on samba server.
Now, the new kernel is running and running also under the high load on samba 
server.

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil