* "NFS: Buggy server - nlink == 0!" & segfault
@ 2009-09-27 20:04 Andy Mastbaum
[not found] ` <4ABFC530.4060504-q5nx0x9Hqjyyum0STUha2w@public.gmane.org>
0 siblings, 1 reply; 2+ messages in thread
From: Andy Mastbaum @ 2009-09-27 20:04 UTC (permalink / raw)
To: linux-nfs
Hello. I have a bunch of Linux (2.6.18-128.1.1.el5, RHEL 5.3) boxen that
mount NFS shares from Solaris, and one died recently in a conflagration
of kernel segfaults following an NFS error:
Sep 11 19:37:12 nubar6 kernel: NFS: Buggy server - nlink == 0!
Sep 11 19:47:57 nubar6 kernel: gdb[28311]: segfault at 00002b4888e73c0b
rip 0000000000508f20 rsp 00007fff4112c988 error 4
Sep 11 19:55:42 nubar6 kernel: NFS: Buggy server - nlink == 0!
Sep 11 19:55:42 nubar6 kernel: NFS: Buggy server - nlink == 0!
Sep 11 20:10:27 nubar6 kernel: NFS: giant filename in readdir (len 201)!
Sep 11 20:10:42 nubar6 kernel: NFS: giant filename in readdir (len 201)!
...
Sep 11 20:36:12 nubar6 kernel: gdb[21443]: segfault at 00002aec9e92d90c
rip 000000000050be3e rsp 00007fff6fa92250 error 4
Sep 11 22:09:42 nubar6 kernel: gdb[6258]: segfault at 000000010b7023b5
rip 0000000000508ea0 rsp 00007fff8d39da88 error 4
...
Perhaps the Solaris NFS server is indeed buggy, but shouldn't this be
caught/handled by the Linux NFS client? Any thoughts/suggestions?
Thanks!
Andy Mastbaum
mastbaum-q5nx0x9Hqjyyum0STUha2w@public.gmane.org
^ permalink raw reply [flat|nested] 2+ messages in thread[parent not found: <4ABFC530.4060504-q5nx0x9Hqjyyum0STUha2w@public.gmane.org>]
* Re: "NFS: Buggy server - nlink == 0!" & segfault [not found] ` <4ABFC530.4060504-q5nx0x9Hqjyyum0STUha2w@public.gmane.org> @ 2009-09-28 18:29 ` Jeff Layton 0 siblings, 0 replies; 2+ messages in thread From: Jeff Layton @ 2009-09-28 18:29 UTC (permalink / raw) To: Andy Mastbaum; +Cc: linux-nfs On Sun, 27 Sep 2009 16:04:00 -0400 Andy Mastbaum <mastbaum-q5nx0x9Hqjyyum0STUha2w@public.gmane.org> wrote: > Hello. I have a bunch of Linux (2.6.18-128.1.1.el5, RHEL 5.3) boxen that > mount NFS shares from Solaris, and one died recently in a conflagration > of kernel segfaults following an NFS error: > > Sep 11 19:37:12 nubar6 kernel: NFS: Buggy server - nlink == 0! > Sep 11 19:47:57 nubar6 kernel: gdb[28311]: segfault at 00002b4888e73c0b > rip 0000000000508f20 rsp 00007fff4112c988 error 4 > Sep 11 19:55:42 nubar6 kernel: NFS: Buggy server - nlink == 0! > Sep 11 19:55:42 nubar6 kernel: NFS: Buggy server - nlink == 0! > Sep 11 20:10:27 nubar6 kernel: NFS: giant filename in readdir (len 201)! > Sep 11 20:10:42 nubar6 kernel: NFS: giant filename in readdir (len 201)! > ... > Sep 11 20:36:12 nubar6 kernel: gdb[21443]: segfault at 00002aec9e92d90c > rip 000000000050be3e rsp 00007fff6fa92250 error 4 > Sep 11 22:09:42 nubar6 kernel: gdb[6258]: segfault at 000000010b7023b5 > rip 0000000000508ea0 rsp 00007fff8d39da88 error 4 > ... > > Perhaps the Solaris NFS server is indeed buggy, but shouldn't this be > caught/handled by the Linux NFS client? Any thoughts/suggestions? > > Thanks! > Did the kernel actually spew an oops as well? >From what you've posted here, it doesn't look like the kernel panicked. If not, then I suspect that the userspace programs doing the readdir weren't expecting filenames as large as those that were returned. As to why that happened in the first place, it's also hard to say. I suspect that the data that he client was trying to parse was corrupt. Either the server sent a corrupt response to the readdir, or something happened to throw the alignment off and cause the response parser to fall down. Either way, we probably wouldn't be able to tell w/o more info. A reliable way to reproduce it would be helpful. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-09-28 18:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-27 20:04 "NFS: Buggy server - nlink == 0!" & segfault Andy Mastbaum
[not found] ` <4ABFC530.4060504-q5nx0x9Hqjyyum0STUha2w@public.gmane.org>
2009-09-28 18:29 ` Jeff Layton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox