lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: lockd problems

Hello. I had exactly the same problem, when i applied knfsd 1.4.4
patches to a stock 2.2.10 kernel. When people started working next day,
lockd oopsed. I rebooted the machine to find it oopsing again in a couple
of seconds. Got back imediately to kernel 2.2.7 with the same patches i
had before. At least it doesnt oops on me, besides a problem i am
evaluating now. Here comes a copy of the oops:


Unable to handle kernel NULL pointer dereference at virtual address
0000000c
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c018e264>]
EFLAGS: 00010202
eax: 00000004 ebx: c832bc80 ecx: 00000050 edx: c963c400
esi: fffffff4 edi: c0165220 ebp: 00000004 esp: c9081dc4
ds: 0018 es: 0018 ss: 0018
Process lockd (pid: 605, process nr: 53, stackpage=c9081000)
Stack: c832bc80 c74d1d40 c963c400 00000004 0000000c 00000002 fffffeff
ffffffff
00000015 c5b088e0 c0214d58 c5b088e0 c74d1d5c c018e5cb c018e5f8
c6884de0
c6884de0 c018df4e c5b088e0 c5b088e0 c0189b1a 00000001 c5b088e0
c9080000
Call Trace: [<c018e5cb>] [<c018e5f8>] [<c018df4e>] [<c0189b1a>]
[<c0163234>] [<c
01627e5>] [<c0165220>]
[<c0165200>] [<c0165220>] [<c0164d25>] [<c0164cdc>] [<c01850e8>]
[<c018f5
c5>] [<c0165f63>] [<c0165fba>]
[<c018f065>] [<c0163500>] [<c018f8ee>] [<c01636ee>] [<c0107aef>]
Code: 66 ff 40 08 8b 4b 1c 8b 43 14 8b 50 18 a1 54 e1 20 c0 03 42



TA

On Fri, 16 Jul 1999, Steven N. Hirsch wrote:

> H.J.,
>
> I'm having serious problems with NFS file locking. I'm running 2.2.10
> with Alan Cox's patchset ac10 applied. This has (AFAIK) all of your knfsd
> fixes except for standalone lockd, which I originally added on top of his
> (no conflicts whatever).
>
> Running a simple back-and-forth lock test between two processes on the
> client sharing a file on the server, lockd crashes immediately:
>
> Jul 15 21:34:40 pii kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c
> Jul 15 21:34:40 pii kernel: current->tss.cr3 = 00101000, `r3 = 00101000
> Jul 15 21:34:40 pii kernel: *pde = 00000000
> Jul 15 21:34:40 pii kernel: Oops: 0002
> Jul 15 21:34:40 pii kernel: CPU: 1
> Jul 15 21:34:40 pii kernel: EIP: 0010:[<c017d18c>]
> Jul 15 21:34:40 pii kernel: EFLAGS: 00013202
> Jul 15 21:34:40 pii kernel: eax: 00000004 ebx: cf6c03c0 ecx: cf6c0820 edx: 00000004
> Jul 15 21:34:40 pii kernel: esi: fffffff4 edi: c01516dc ebp: 00000002 esp: cf91fe0c
> Jul 15 21:34:40 pii kernel: ds: 0018 es: 0018 ss: 0018
> Jul 15 21:34:40 pii kernel: Process lockd (pid: 203, process nr: 11, stackpage=cf91f000)
> Jul 15 21:34:40 pii kernel: Stack: cf6c03c0 cf6c00a0 ce79fc00 00000004 0000000f cf91fe24 fffffeff ffffffff
> Jul 15 21:34:40 pii kernel: cf757000 00000000 c0000000 cf91e000 cfcb75c0 400b9000 cfcb7340 c012e3b0
> Jul 15 21:34:40 pii kernel: 00000246 cfcb7240 cf91e000 00000001 cf9351d0 00000001 464c457f 00010101
> Jul 15 21:34:40 pii kernel: Call Trace: [<c012e3b0>] [<c0112111>] [<c014ed2f>] [<c01516dc>] [<c01516c4>] [<c01516dc>] [<c0151323>]
> Jul 15 21:34:40 pii kernel: [<c011217e>] [<c0115154>] [<c0152213>] [<c0152264>] [<c017dee2>] [<c014fc8a>] [<c0107b8b>]
> Jul 15 21:34:40 pii kernel: Code: 66 ff 40 08 8b 43 14 8b 4b 1c 8b 50 18 a1 80 e1 20 c0 03 42
> Copying default arch from ksymoops, bfd_arch=8 bfd_mach=0
>
> >>EIP; c017d18c <rpcauth_releasecred+24/54>
> Trace; c012e3b0 <do_execve+198/1d8>
> Trace; c0112111 <reschedule_idle+1b9/1d4>
> Trace; c014ed2f <nlmclnt_test+17/4c>
> Trace; c01516dc <nlmsvc_callback_exit+40/54>
> Trace; c01516c4 <nlmsvc_callback_exit+28/54>
> Trace; c01516dc <nlmsvc_callback_exit+40/54>
> Trace; c0151323 <nlmsvc_proc_share+37/cc>
> Trace; c011217e <wake_up_process+52/68>
> Trace; c0115154 <do_fork+7ac/8c8>
> Trace; c0152213 <nlmsvc_decode_testargs+eb/19c>
> Trace; c0152264 <nlmsvc_decode_testargs+13c/19c>
> Trace; c017dee2 <svc_process+266/554>
> Trace; c014fc8a <lockd+24a/294>
> Trace; c0107b8b <kernel_thread+23/30>
> Code; c017d18c <rpcauth_releasecred+24/54> 00000000 <_EIP>:
> Code; c017d18c <rpcauth_releasecred+24/54> 0: 66 ff 40 08 incw 0x8(%eax)
> Code; c017d190 <rpcauth_releasecred+28/54> 4: 8b 43 14 movl 0x14(%ebx),%eax
> Code; c017d193 <rpcauth_releasecred+2b/54> 7: 8b 4b 1c movl 0x1c(%ebx),%ecx
> Code; c017d196 <rpcauth_releasecred+2e/54> a: 8b 50 18 movl 0x18(%eax),%edx
> Code; c017d199 <rpcauth_releasecred+31/54> d: a1 80 e1 20 c0 movl 0xc020e180,%eax
> Code; c017d19e <rpcauth_releasecred+36/54> 12: 03 42 00 addl 0x0(%edx),%eax
>
>
> I backed out the lockd patch and reverted to the knfsd utilities 1.4.2
> with the same results:
>
> Jul 16 16:39:34 pii kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c
> Jul 16 16:39:34 pii kernel: current->tss.cr3 = 00101000, `r3 = 00101000
> Jul 16 16:39:34 pii kernel: *pde = 00000000
> Jul 16 16:39:34 pii kernel: Oops: 0002
> Jul 16 16:39:34 pii kernel: CPU: 1
> Jul 16 16:39:34 pii kernel: EIP: 0010:[<c017d14c>]
> Jul 16 16:39:34 pii kernel: EFLAGS: 00010202
> Jul 16 16:39:34 pii kernel: eax: 00000004 ebx: cf768140 ecx: cf71da40 edx: 00000004
> Jul 16 16:39:34 pii kernel: esi: fffffff4 edi: c015169c ebp: 00000002 esp: cf5d1e0c
> Jul 16 16:39:34 pii kernel: ds: 0018 es: 0018 ss: 0018
> Jul 16 16:39:34 pii kernel: Process lockd (pid: 297, process nr: 26, stackpage=cf5d1000)
> Jul 16 16:39:34 pii kernel: Stack: cf768140 cf7681e0 cda4ea00 00000004 0000000f cf5d1e24 fffffeff ffffffff
> Jul 16 16:39:34 pii kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Jul 16 16:39:34 pii kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Jul 16 16:39:34 pii kernel: Call Trace: [<c014ecff>] [<c015169c>] [<c0151684>] [<c015169c>] [<c01512e3>] [<c011217e>] [<c0115154>]
> Jul 16 16:39:34 pii kernel: [<c01521d3>] [<c0152224>] [<c017dea2>] [<c014fc5a>] [<c0107b8b>]
> Jul 16 16:39:34 pii kernel: Code: 66 ff 40 08 8b 43 14 8b 4b 1c 8b 50 18 a1 40 e0 20 c0 03 42
> Copying default arch from ksymoops, bfd_arch=8 bfd_mach=0
>
> >>EIP; c017d14c <rpcauth_holdcred+38/54>
> Trace; c014ecff <nlmclnt_async_call+9b/b4>
> Trace; c015169c <nlmsvc_callback_exit+0/54>
> Trace; c0151684 <nlmsvc_callback+70/88>
> Trace; c015169c <nlmsvc_callback_exit+0/54>
> Trace; c01512e3 <nlmsvc_proc_granted_msg+47/50>
> Trace; c011217e <wake_up_process+52/68>
> Trace; c0115154 <do_fork+7ac/8c8>
> Trace; c01521d3 <nlmsvc_decode_testargs+ab/19c>
> Trace; c0152224 <nlmsvc_decode_testargs+fc/19c>
> Trace; c017dea2 <svc_process+226/554>
> Trace; c014fc5a <lockd+21a/294>
> Trace; c0107b8b <kernel_thread+23/30>
> Code; c017d14c <rpcauth_holdcred+38/54> 00000000 <_EIP>:
> Code; c017d14c <rpcauth_holdcred+38/54> 0: 66 ff 40 08 incw 0x8(%eax)
> Code; c017d150 <rpcauth_holdcred+3c/54> 4: 8b 43 14 movl 0x14(%ebx),%eax
> Code; c017d153 <rpcauth_holdcred+3f/54> 7: 8b 4b 1c movl 0x1c(%ebx),%ecx
> Code; c017d156 <rpcauth_holdcred+42/54> a: 8b 50 18 movl 0x18(%eax),%edx
> Code; c017d159 <rpcauth_holdcred+45/54> d: a1 40 e0 20 c0 movl 0xc020e040,%eax
> Code; c017d15e <rpcauth_holdcred+4a/54> 12: 03 42 00 addl 0x0(%edx),%eax
>
>
> Looks like the same underlying problem.
>
> I have attached the somewhat-simpleminded programs used to run the test.
> It's 100% repeatable here between two Intel boxes (one SMP, one UP)
> running the identical kernels and utilities in both cases.
>
> Let me know if you need more information?
>
> Steve
>
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.064 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site