From: sdrb <sdrb@onet.eu>
To: linux-nfs@vger.kernel.org
Subject: Re: Issue in nfs-utils 1.2.3
Date: Wed, 12 Jan 2011 14:51:20 +0100 [thread overview]
Message-ID: <4D2DB1D8.8030606@onet.eu> (raw)
In-Reply-To: <4D2D910F.1080703@onet.eu>
[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]
On 01/12/2011 12:31 PM, sdrb wrote:
> Hello,
>
>
> Recently I tried to upgrade nfs-utils to the newest nfs-utils 1.2.3.
> During tests I noticed that in some circumstances rpc.mountd
> crashes with segmentation fault.
> I'm testing it with 2.6.36 linux kernel.
>
>
> Configuration of nfs-server:
>
> server# cat /etc/exports
> /export *(rw)
> /tmp/nfs *(rw)
>
>
> The scenario how to reproduce the issue:
>
> server# rpc.mountd -F -d all
> server# showmount -a 127.0.0.1
> host# umount /mnt/nfs2 ; mount -t nfs server:/tmp/nfs /mnt/nfs2 -o
> nfsvers=3,nolock
> server# showmount -a 127.0.0.1
>
>
> and after spawning showmount for the second time I got two segmentation
> faults: at showmount and at rpc.mountd.
>
> Here is output from rpc.mountd:
> rpc.mountd: Received DUMP request from 127.0.0.1
> rpc.mountd: Received NULL request from host
> rpc.mountd: Received UMNT(/tmp/nfs) request from host
> rpc.mountd: authenticated unmount request from host:844 for /tmp/nfs
> (/tmp/nfs)
> rpc.mountd: Received NULL request from host
> rpc.mountd: Received NULL request from host
> rpc.mountd: Received MNT3(/tmp/nfs) request from host
> rpc.mountd: authenticated mount request from host:729 for /tmp/nfs
> (/tmp/nfs)
> rpc.mountd: nfsd_fh: inbuf '* 7
> \x0ab4100000000000dd2efb04e753f0980000000000000000'
> rpc.mountd: nfsd_fh: found 0x1f13380 path /tmp/nfs
> rpc.mountd: Received DUMP request from 127.0.0.1
> Segmentation fault
> .
>
>
> To gather more info I run rpc.mountd in gdb:
>
>
> Starting program: /usr/sbin/rpc.mountd -F
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7b6f7a2 in xdr_string_internal () from /lib64/libc.so.6
>
> #0 0x00007ffff7b6f7a2 in xdr_string_internal () from /lib64/libc.so.6
> #1 0x0000000000409eee in xdr_name (xdrs=<value optimized out>,
> objp=<value optimized out>) at mount_xdr.c:83
> (...)
>
> Seems like two procedures (xdr_mountlist and xdr_mountbody) call one
> another infinitely until they fill the stack completely and then
> segfault occures.
>
> Is it known problem?
> Maybe I misconfigured or missed something?
I've investigated a little the sources and I noticed that probably there
should be some pointer NULL-ed in mountlist_list() procedure like in
patch I've attached.
Anyone can confirm that such a fix is ok?
[-- Attachment #2: d1.diff --]
[-- Type: text/x-patch, Size: 422 bytes --]
diff -rNup nfs-utils-1.2.3_orig/utils/mountd/rmtab.c nfs-utils-1.2.3/utils/mountd/rmtab.c
--- nfs-utils-1.2.3/utils/mountd/rmtab.c 2010-09-28 14:24:16.000000000 +0200
+++ nfs-utils-1.2.3/utils/mountd/rmtab.c 2011-01-12 14:44:22.320000000 +0100
@@ -205,6 +205,7 @@ mountlist_list(void)
}
if (stb.st_mtime != last_mtime) {
mountlist_freeall(mlist);
+ mlist=NULL;
last_mtime = stb.st_mtime;
setrmtabent("r");
next prev parent reply other threads:[~2011-01-12 13:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-12 11:31 Issue in nfs-utils 1.2.3 sdrb
2011-01-12 13:51 ` sdrb [this message]
2011-01-12 16:04 ` J. Bruce Fields
2011-01-13 15:47 ` Chuck Lever
2011-01-13 15:52 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2DB1D8.8030606@onet.eu \
--to=sdrb@onet.eu \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.