Re: more signal locking bugs?

["Martin J. Bligh" <mbligh@aracnet.com>]

> Ok, I committed this alternative change, which isn't quite as minimal, but 
> looks a lot cleaner to me.
> 
> Also, looking at execve() and other paths, we do seem to have sufficient 
> protection from the tasklist_lock that signal delivery should be fine. So 
> despite a long and confused thread, I think in the end the only real bug 
> was the one Martin found which should be thus fixed..

Ran your patch ... but I get plenty of these now:

Unable to handle kernel NULL pointer dereference at virtual address 00000004
 printing eip:
c016d5a8
*pde = 2e10f001
*pte = 00000000
Oops: 0000
CPU:    2
EIP:    0060:[<c016d5a8>]    Not tainted
EFLAGS: 00010202
EIP is at collect_sigign_sigcatch+0x1c/0x44
eax: ed6d72c0   ebx: ed403f50   ecx: 00000004   edx: 00000001
esi: ed403f48   edi: ed6d72c0   ebp: 00000000   esp: ed403eec
ds: 007b   es: 007b   ss: 0068
Process ps (pid: 19988, threadinfo=ed402000 task=ed9352a0)
Stack: c011d115 c02af820 c016dab8 ed6d72c0 ed403f48 ed403f50 ed6d72c0 edb99a50 
       ed6d72c0 eebf33c0 ee225000 c034e400 ed403f50 ed403f48 00000000 52000000 
       00008800 00000125 eebf33c0 eebf33e0 00000000 00000000 00000000 000000d0 
Call Trace:
 [<c011d115>] do_exit+0x30d/0x31c
 [<c016dab8>] proc_pid_stat+0x110/0x324
 [<c0130076>] __get_free_pages+0x4e/0x54
 [<c016b497>] proc_info_read+0x53/0x130
 [<c0145215>] vfs_read+0xa5/0x128
 [<c01454a2>] sys_read+0x2a/0x3c
 [<c0108b3f>] syscall_call+0x7/0xb

Code: 8b 01 83 f8 01 75 08 8d 42 ff 0f ab 06 eb 0a 85 c0 74 06 8d