From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: NFSv3 list <linux-nfs@vger.kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Jeff Layton <jlayton@redhat.com>,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: kernel panic when mount NFSv4
Date: Tue, 21 Dec 2010 13:38:44 +0800 [thread overview]
Message-ID: <4D103D64.30700@cn.fujitsu.com> (raw)
In-Reply-To: <1292879966.7744.4.camel@heimdal.trondhjem.org>
Trond Myklebust 写道:
> On Tue, 2010-12-14 at 16:58 +0800, Mi Jinlong wrote:
>> Hi,
>>
>> When testing NFSv4 at RHEL6 with kernel 2.6.32, I got a kernel panic
>> at NFS client's __rpc_create_common function.
>>
>> The panic place is:
>> rpc_mkpipe
>> __rpc_lookup_create() <=== find pipefile *idmap*
>> __rpc_mkpipe() <=== pipefile is *idmap*
>> __rpc_create_common()
>> ****** BUG_ON(!d_unhashed(dentry)); ****** *panic*
>>
>> It means that the dentry's d_flags have be set DCACHE_UNHASHED,
>> but it should not be set here.
>>
>> Is someone known this bug? or give me some idea?
>>
>> A reproduce program is append, but it can't reproduce the bug every time.
>> the export is: "/nfsroot *(rw,no_root_squash,fsid=0,insecure)"
>>
>> And the panic message is append.
>>
>> ============================================================================
>> #!/bin/sh
>>
>> LOOPTOTAL=768
>> LOOPCOUNT=0
>> ret=0
>>
>> while [ $LOOPCOUNT -ne $LOOPTOTAL ]
>> do
>> ((LOOPCOUNT += 1))
>> service nfs restart
>> /usr/sbin/rpc.idmapd
>> mount -t nfs4 127.0.0.1:/ /mnt|| return 1;
>> ls -l /var/lib/nfs/rpc_pipefs/nfs/*/
>> umount /mnt
>> echo $LOOPCOUNT
>> done
>>
>> ===============================================================================
>> Code: af 60 01 00 00 89 fa 89 f0 e8 64 cf 89 f0 e8 5c 7c 64 cf 31 c0 8b 5c 24 10 8b
>> 74 24 14 8b 7c 24 18 8b 6c 24 1c 83 c4 20 c3 <0f> 0b eb fc 8b 46 28 c7 44 24 08 20
>> de ee f0 c7 44 24 04 56 ea
>> EIP:[<f0ee92ea>] __rpc_create_common+0x8a/0xc0 [sunrpc] SS:ESP 0068:eccb5d28
>> ---[ end trace 8f5606cd08928ed2]---
>> Kernel panic - not syncing: Fatal exception
>> Pid:7131, comm: mount.nfs4 Tainted: G D -------------------2.6.32 #1
>> Call Trace:
>> [<c080ad18>] ? panic+0x42/0xed
>> [<c080e42c>] ? oops_end+0xbc/0xd0
>> [<c040b090>] ? do_invalid_op+0x0/0x90
>> [<c040b10f>] ? do_invalid_op+0x7f/0x90
>> [<f0ee92ea>] ? __rpc_create_common+0x8a/0xc0[sunrpc]
>> [<f0edc433>] ? rpc_free_task+0x33/0x70[sunrpc]
>> [<f0ed6508>] ? prc_call_sync+0x48/0x60[sunrpc]
>> [<f0ed656e>] ? rpc_ping+0x4e/0x60[sunrpc]
>> [<f0ed6eaf>] ? rpc_create+0x38f/0x4f0[sunrpc]
>> [<c080d80b>] ? error_code+0x73/0x78
>> [<f0ee92ea>] ? __rpc_create_common+0x8a/0xc0[sunrpc]
>> [<c0532bda>] ? d_lookup+0x2a/0x40
>> [<f0ee94b1>] ? rpc_mkpipe+0x111/0x1b0[sunrpc]
>> [<f10a59f4>] ? nfs_create_rpc_client+0xb4/0xf0[nfs]
>> [<f10d6c6d>] ? nfs_fscache_get_client_cookie+0x1d/0x50[nfs]
>> [<f10d3fcb>] ? nfs_idmap_new+0x7b/0x140[nfs]
>> [<c05e76aa>] ? strlcpy+0x3a/0x60
>> [<f10a60ca>] ? nfs4_set_client+0xea/0x2b0[nfs]
>> [<f10a6d0c>] ? nfs4_create_server+0xac/0x1b0[nfs]
>> [<c04f1400>] ? krealloc+0x40/0x50
>> [<f10b0e8b>] ? nfs4_remote_get_sb+0x6b/0x250[nfs]
>> [<c04f14ec>] ? kstrdup+0x3c/0x60
>> [<c0520739>] ? vfs_kern_mount+0x69/0x170
>> [<f10b1a3c>] ? nfs_do_root_mount+0x6c/0xa0[nfs]
>> [<f10b1b47>] ? nfs4_try_mount+0x37/0xa0[nfs]
>> [<f10afe6d>] ? nfs4_validate_text_mount_data+-x7d/0xf0[nfs]
>> [<f10b1c42>] ? nfs4_get_sb+0x92/0x2f0
>> [<c0520739>] ? vfs_kern_mount+0x69/0x170
>> [<c05366d2>] ? get_fs_type+0x32/0xb0
>> [<c052089f>] ? do_kern_mount+0x3f/0xe0
>> [<c053954f>] ? do_mount+0x2ef/0x740
>> [<c0537740>] ? copy_mount_options+0xb0/0x120
>> [<c0539a0e>] ? sys_mount+0x6e/0xa0
>
> Hi,
>
> Does the following patch fix the problem?
Thanks Trond.
After this patch, NFS client runs correctly.
>
> Cheers
> Trond
>
> --------------------------
> SUNRPC: Fix a BUG in __rpc_create_common
>
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> Mi Jinlong reports:
>
>
> When testing NFSv4 at RHEL6 with kernel 2.6.32, I got a kernel panic
> at NFS client's __rpc_create_common function.
>
> The panic place is:
> rpc_mkpipe
> __rpc_lookup_create() <=== find pipefile *idmap*
> __rpc_mkpipe() <=== pipefile is *idmap*
> __rpc_create_common()
> ****** BUG_ON(!d_unhashed(dentry)); ****** *panic*
>
> The test is wrong: we can find ourselves with a hashed negative dentry here
> if the idmapper tried to look up the file before we got round to creating
> it.
>
> Just replace the BUG_ON() with a d_drop(dentry).
>
> Reported-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
>
> net/sunrpc/rpc_pipe.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
> index 10a17a3..5356d95 100644
> --- a/net/sunrpc/rpc_pipe.c
> +++ b/net/sunrpc/rpc_pipe.c
> @@ -466,7 +466,7 @@ static int __rpc_create_common(struct inode *dir, struct dentry *dentry,
> {
> struct inode *inode;
>
> - BUG_ON(!d_unhashed(dentry));
> + d_drop(dentry);
> inode = rpc_get_inode(dir->i_sb, mode);
> if (!inode)
> goto out_err;
>
>
--
----
thanks
Mi Jinlong
next prev parent reply other threads:[~2010-12-21 5:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-14 8:58 kernel panic when mount NFSv4 Mi Jinlong
2010-12-20 10:01 ` Mi Jinlong
2010-12-20 21:19 ` Trond Myklebust
2010-12-21 5:38 ` Mi Jinlong [this message]
2012-12-14 5:39 ` [2.6.32.y, 2.6.34.y] " Jonathan Nieder
2012-12-14 7:17 ` Willy Tarreau
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=4D103D64.30700@cn.fujitsu.com \
--to=mijinlong@cn.fujitsu.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).