Re: 2.1.66 Oopses

Andrew Walker (andy@lysaker.kvaerner.no)
Fri, 28 Nov 1997 08:40:20 +0100 (MET)

Graffiti wrote:
>
> Hi all!
>
> Got these a short while ago:
>
> The only modification made was by ppp-2.3.1's kinstall
> script and a few ppp patches to get it to compile with glibc2,
> + a 2.3.1->2.3.2 patch.
>
> Unable to handle kernel NULL pointer dereference at virtual address 000000e5
> current->tss.cr3 = 00101000, Lr3 = 00101000
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c012c2c8>]
> EFLAGS: 00010202
> eax: c10e7c63 ebx: c10e7cbf ecx: c10e7c63 edx: c0e73120
> esi: 000000c1 edi: c0ee5ce0 ebp: c0e735a0 esp: c08f7eb4
> ds: 0018 es: 0018 ss: 0018
> Process grep (pid: 1064, process nr: 32, stackpage=c08f7000)
> Stack: c0e735a0 00000003 c0ee5ce0 00000001 c10e7c63 00000000 c0976540 c0976540
> c09765dc c11178dc c012dcbf c0976540 c11178a0 c0e73120 c11710f4 c0121a9b
> c0976540 c0e73120 00000000 c0ee5ce0 c0121adf c08f6000 c0e735a0 00000001
> Call Trace: [<c012dcbf>] [<c0121a9b>] [<c0121adf>] [<c0114da8>] [<c01096ec>] [<c0186add>] [<c0187649>]
> [<c010ddfe>] [<c0187649>] [<c010933a>] [<c01274c4>] [<c01091fa>]
> Code: 8a 46 24 a8 01 74 09 8b 4c 24 54 39 4e 14 74 10 a8 02 74 48

> >>EIP: c012c2c8 <locks_remove_locks+28/94>
> Trace: c012dcbf <dput+8b/f4>
> Trace: c0121a9b <__fput+43/50>
> Trace: c0121adf <close_fp+37/80>
> Trace: c0114da8 <do_exit+fc/1f0>
> Trace: c01096ec <die_if_kernel+44/48>
> Trace: c0186add <sprintf+20b1/2988>
> Trace: c0187649 <bad_pmd_string+295/2c8>
> Trace: c010ddfe <do_page_fault+31a/32c>
> Trace: c0187649 <bad_pmd_string+295/2c8>
> Trace: c010933a <error_code+32/3c>
> Trace: c01274c4 <sys_newfstat+3c/68>
> Trace: c01091fa <system_call+3a/40>
> Code: c012c2c8 <locks_remove_locks+28/94>
> Code: c012c2c8 <locks_remove_locks+28/94> 8a 46 24 movb 0x24(%esi),%al
> Code: c012c2cb <locks_remove_locks+2b/94> a8 01 testb $0x1,%al
> Code: c012c2cd <locks_remove_locks+2d/94> 74 09 je c012c2d8 <locks_remove_locks+38/94>
> Code: c012c2cf <locks_remove_locks+2f/94> 8b 4c 24 54 movl 0x54(%esp,1),%ecx
> Code: c012c2d9 <locks_remove_locks+39/94> 39 4e 14 cmpl %ecx,0x14(%esi)
> Code: c012c2dc <locks_remove_locks+3c/94> 74 10 je c012c2e8 <locks_remove_locks+48/94>
> Code: c012c2de <locks_remove_locks+3e/94> a8 02 testb $0x2,%al
> Code: c012c2e0 <locks_remove_locks+40/94> 74 48 je c012c324 <locks_remove_locks+84/94>

Hi Bill et. al.,

Looks like close_fp() is handing locks_remove_locks() a file pointer
with a NULL dentry. At the moment there are no pointer checks in
lock_remove_locks() because this didn't used to be possible.

I don't know whether locks_remove_locks() should handle this case, or
whether to handle it before deciding to call locks_remove_locks() or
whether perhaps it is symptomatic of a dentry problem i.e. that the NULL
dentry is a bug in itself, not just a new case for us to handle.

Comments?

-Andy

-- 
Andy Walker                              Kvaerner Engineering a.s.
Andrew.Walker@lysaker.kvaerner.no        P.O. Box 222, N-1324 Lysaker, Norway


   ......if the answer isn't violence, neither is your silence......


(pwei barmy army - oslo "filial")