lockd problems

Steven N. Hirsch (shirsch@adelphia.net)
Fri, 16 Jul 1999 16:59:32 -0400 (EDT)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

---1463804171-850528062-932158772=:1510
Content-Type: TEXT/PLAIN; charset=US-ASCII

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

---1463804171-850528062-932158772=:1510
Content-Type: APPLICATION/x-sh; name="runtest.sh"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9907161659320.1510@pii.fast.net>
Content-Description:
Content-Disposition: attachment; filename="runtest.sh"

IyEvYmluL3NoCgo+IHRlc3QuZmlsZQoKLi9sb2NrZXIgJgpzbGVlcCAxCmVj
aG8gIiIKLi9sb2NrZXIK
---1463804171-850528062-932158772=:1510
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="locker.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9907161659321.1510@pii.fast.net>
Content-Description:
Content-Disposition: attachment; filename="locker.c"

I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5j
bHVkZSA8YXNzZXJ0Lmg+DQoNCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNp
bmNsdWRlIDxzeXMvc3RhdC5oPg0KI2luY2x1ZGUgPGZjbnRsLmg+DQojaW5j
bHVkZSA8dGltZS5oPg0KDQovKiBGcm9tIFN0ZXZlbnMgQVBVRSBib29rLiAq
Lw0KaW50DQpsb2NrX3JlZyhpbnQgZmQsIGludCBjbWQsIGludCB0eXBlLCBv
ZmZfdCBvZmZzZXQsIGludCB3aGVuY2UsIG9mZl90IGxlbikNCnsNCglzdHJ1
Y3QgZmxvY2sJbG9jazsNCg0KCWxvY2subF90eXBlID0gdHlwZTsJCS8qIEZf
UkRMQ0ssIEZfV1JMQ0ssIEZfVU5MQ0sgKi8NCglsb2NrLmxfc3RhcnQgPSBv
ZmZzZXQ7CS8qIGJ5dGUgb2Zmc2V0LCByZWxhdGl2ZSB0byBsX3doZW5jZSAq
Lw0KCWxvY2subF93aGVuY2UgPSB3aGVuY2U7CS8qIFNFRUtfU0VULCBTRUVL
X0NVUiwgU0VFS19FTkQgKi8NCglsb2NrLmxfbGVuID0gbGVuOwkJLyogI2J5
dGVzICgwIG1lYW5zIHRvIEVPRikgKi8NCg0KCXJldHVybiggZmNudGwoZmQs
IGNtZCwgJmxvY2spICk7DQp9DQoNCg0KaW50DQptYWluKCB2b2lkICkNCnsN
CiAgY2hhciBidWZbMTI4XTsNCiAgdGltZV90IHQ7DQogIGludCBmZDsNCiAg
cGlkX3QgbWU7DQogIGludCB0cmllcyA9IDEwOw0KICANCiAgbWUgPSBnZXRw
aWQoKTsNCiAgDQogIGZkID0gb3BlbiggInRlc3QuZmlsZSIsIE9fQVBQRU5E
fE9fUkRXUiwgU19JUlVTUnxTX0lXVVNSICk7DQogIGFzc2VydChmZCAhPSAt
MSk7DQogICAgDQogIHdoaWxlICh0cmllcykgew0KICAgIGlmICggbG9ja19y
ZWcoZmQsIEZfU0VUTEssIEZfV1JMQ0ssIDAsIFNFRUtfU0VULCAwICkgPT0g
LTEgKSB7DQogICAgICBwcmludGYoIiVkOiBDYW4ndCBnZXQgd3JpdGUgbG9j
aywgSSdsbCBzbGVlcCBvbiBpdC4uXG4iLCBtZSk7DQogICAgICBpZiAoIGxv
Y2tfcmVnKGZkLCBGX1NFVExLVywgRl9XUkxDSywgMCwgU0VFS19TRVQsIDAg
PT0gLTEgKSApIHsNCglwZXJyb3IoImxvY2t0ZXN0Iik7DQoJZXhpdCgxKTsN
CiAgICAgIH0NCiAgICB9DQogICAgDQogICAgcHJpbnRmKCIlZDogSGF2ZSB3
cml0ZSBsb2NrLCBhcHBlbmRpbmcgdG8gZmlsZVxuIiwgbWUpOw0KICAgIA0K
ICAgIHNwcmludGYoYnVmLCAiJWQ6ICIsIG1lKTsNCiAgICB0aW1lKCZ0KTsN
CiAgICBzdHJjYXQoYnVmLCBjdGltZSgmdCkpOw0KICAgIHdyaXRlKGZkLCBi
dWYsIHN0cmxlbihidWYpKTsNCiAgICANCiAgICBzbGVlcCg1KTsNCiAgICAN
CiAgICBwcmludGYoIiVkOiBSZWxlYXNpbmcgbG9jay4uXG4iLCBtZSk7DQog
ICAgDQogICAgaWYgKCBsb2NrX3JlZyhmZCwgRl9TRVRMSywgRl9VTkxDSywg
MCwgU0VFS19TRVQsIDAgKSA9PSAtMSApIHsNCiAgICAgIHBlcnJvcigibG9j
a3Rlc3QiKTsNCiAgICAgIGV4aXQoMSk7DQogICAgfQ0KICAgIHNsZWVwKDEp
Ow0KICAgIHRyaWVzLS07DQogIH0NCiAgDQogIGNsb3NlKGZkKTsNCiAgcmV0
dXJuIDA7DQogIA0KfQ0KDQo=
---1463804171-850528062-932158772=:1510--

-
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/