Hi,
I am having a very similar problem to the one reported
by Joachim Selke on the nfsv4 mailing list (see
http://linux-nfs.org/pipermail/nfsv4/2006-October/005226.html).
This might be out of the domain of the nfsv4 folks, so I'm
posting here now.
I recently upgraded my client and server side kernels
to 2.6.18. I am unable to mount a second NFSv3+krb5
share after already mounting another one somewhere else
on the system. For example,
"mount server:/export/home /net/home" works, but a
subsequent
"mount server:/export/data /net/data" returns
mount.nfs: File exists
I have no problems when performing the same with the
client running 2.6.17 and the server running 2.6.18.
I have been using NFSv3+krb5 for a long time with no
problems. My exports file on the server looks like:
/export/data gss/krb5(secure,rw,sync,wdelay,hide,no_subtree_check,auth_nlm,root_squash,anonuid=65534,anongid=65534)
/export/data 192.168.0.0/24(secure,ro,sync,all_squash,anonuid=65534,anongid=65534)
which is the accepted way to export a NFSv3+krb5
volume since the non-krb5 export is used for mounting
and the krb5 export is used for actual file access.
(Also, my distribution is FC5 on the
client and the server except for a slight version upgrade
of util-linux and nfs-utils on the server to get around the
following problem:
http://linux-nfs.org/pipermail/nfsv4/2006-July/004694.html.)
Finally, I have done a wireshark dump and the initial part
of the RPC occurs with no problems but then the do_mount_syscall
function in mount.nfs:mount.c fails. So I really think this is a
client side issue. This guess is also supported by the fact
that the same 2.6.18 server works with a 2.6.17 client but
not a 2.6.18 client.
This is a very important issue for me so whatever advice
you can provide would be much appreciated. I am happy
to provide more debugging information if you can tell me
what to turn on. With my current installation I see *nothing*
in /var/log/messages on either the server or the client
when mount spits out its error.
Thanks in advance,
Paarvai
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi all,
I think I have found the answer. It is similar to this issue but not
exactly the same as:
http://linux-nfs.org/pipermail/nfsv4/2005-November/002807.html
Here's what is happening. In 2.6.18 there is a new file called
fs/nfs/client.c. In this file it does the following for every new
mount:
1) Lookup to see if an existing client has the same specification
as the requested mount.
2) If so, clone that client. If not, create a new one.
3) Create any pipes required by the auth pseudoflavor by
calling rpcauth_create.
4) Continue with the mounting of the volume.
Now, if you have no connections to the server, a new rpc
client is created and the pipes are created with no problems.
For the second mount to the same server, the rpc client is
cloned and has the same path in /var/lib/nfs/rpc_pipefs/nfs
has the first connection. Therefore on step 3 the pipe creation
fails in net/sunrpc/auth_gss/auth_gss.c. This causes the
entire mount to fail.
This is a serious bug that prevents important functionality
of nfsv3 with krb5. I notice that kernel 2.6.19 is on release
candidate 5. Is there any way a surgical fix can be inserted
into 2.6.19 before final release?
This bug does not exist under 2.6.17 since client directories
in /var/lib/nfs/rpc_pipefs/nfs are not reused across different
nfsv3+krb5 mounts to the same server.
Thanks,
Paarvai
----- Original Message ----
From: Open Source <[email protected]>
To: J. Bruce Fields <[email protected]>
Cc: [email protected]
Sent: Wednesday, November 15, 2006 10:37:16 AM
Subject: Re: "mount: File exists" when trying to mount a second krb5 volume!
A couple more things:
I notice there is a new client.c for 2.6.18. Maybe the problem lies
there as code was ported from other places into that file?
My error only shows up with nfsv3,krb5 mounts. My volumes also
have acls but I'm guessing that that is not causing any problems.
Thanks,
Paarvai
----- Original Message ----
From: Open Source <[email protected]>
To: J. Bruce Fields <[email protected]>
Cc: [email protected]
Sent: Monday, November 13, 2006 2:16:11 PM
Subject: Re: "mount: File exists" when trying to mount a second krb5 volume!
Hi Bruce,
Regarding whether there is an error reply from the server, I
looked at the "MOUNT V3 MNT Reply (Call In 46)" packet
(which is the last MOUNT packet in the dump summary I
sent previously). This packet is going from the server
to the client. When I look at it in the "Packet Details" (tree view)
under the "Mount Service" line, it says "Status: OK (0)"
so I guess there are no errors.
Yes, I did do an "exportfs -a" on the server after twiddling
the root_squash business.
Also, I am not trying to mount the same export in two places.
On the client I have mounted server:/export/home to /net/home
and then things fail when I try to mount server:/export/data to
/net/data.
Yes, I do think it is client side. Things work when the client
is 2.6.17 and the server is 2.6.18 but not when the client is
2.6.18.
Is there some logging I can do on the client side to see what
might be happening?
Thanks,
Paarvai
----- Original Message ----
From: J. Bruce Fields <[email protected]>
To: Open Source <[email protected]>
Cc: [email protected]
Sent: Monday, November 13, 2006 1:08:29 PM
Subject: Re: "mount: File exists" when trying to mount a second krb5 volume!
On Mon, Nov 13, 2006 at 12:31:20PM -0800, Open Source wrote:
> Here's a sanitized summary of my traffic. I don't know how useful
> this might be, but if there is a specific line that might be helpful
> I can expand that and possibly send it to you.
OK, so none of those server replies are errors? Then I guess it's the
client complaining.
Are you trying to mount the same export in two different places? I
think some of the recent client changes may prevent that.
--b.
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Wed, Nov 15, 2006 at 06:31:17PM -0800, Open Source wrote:
> Here's what is happening.
Thanks for your persistence!
> For the second mount to the same server, the rpc client is
> cloned and has the same path in /var/lib/nfs/rpc_pipefs/nfs
> has the first connection. Therefore on step 3 the pipe creation
> fails in net/sunrpc/auth_gss/auth_gss.c. This causes the
> entire mount to fail.
Argh, I could swear we've tried to fix this problem at least twice
before....
> This is a serious bug that prevents important functionality
> of nfsv3 with krb5. I notice that kernel 2.6.19 is on release
> candidate 5. Is there any way a surgical fix can be inserted
> into 2.6.19 before final release?
I'll take a look tommorow if someone else doesn't beat me to it, but I
doubt we'll get it done that fast.
--b.
Hi Bruce,
Sure. It was a bit frustrating learning the sysctl debug
infrastructure for the first time and weeding through
the code to add more debug statements, but I'm glad
I got to the bottom of things.
Please let me know if there is a quick fix for this
problem. It would be idea to get this into the
main kernel tree as soon as possible.
Thanks again,
Paarvai
----- Original Message ----
From: J. Bruce Fields <[email protected]>
To: Open Source <[email protected]>
Cc: [email protected]; [email protected]
Sent: Wednesday, November 15, 2006 7:51:29 PM
Subject: Re: "mount: File exists" when trying to mount a second krb5 volume!
On Wed, Nov 15, 2006 at 06:31:17PM -0800, Open Source wrote:
> Here's what is happening.
Thanks for your persistence!
> For the second mount to the same server, the rpc client is
> cloned and has the same path in /var/lib/nfs/rpc_pipefs/nfs
> has the first connection. Therefore on step 3 the pipe creation
> fails in net/sunrpc/auth_gss/auth_gss.c. This causes the
> entire mount to fail.
Argh, I could swear we've tried to fix this problem at least twice
before....
> This is a serious bug that prevents important functionality
> of nfsv3 with krb5. I notice that kernel 2.6.19 is on release
> candidate 5. Is there any way a surgical fix can be inserted
> into 2.6.19 before final release?
I'll take a look tommorow if someone else doesn't beat me to it, but I
doubt we'll get it done that fast.
--b.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Nov 15, 2006 at 06:31:17PM -0800, Open Source wrote:
....
> This bug does not exist under 2.6.17 since client directories
> in /var/lib/nfs/rpc_pipefs/nfs are not reused across different
> nfsv3+krb5 mounts to the same server.
For the record I have the same problem with nfs4+krb5 in 2.6.18
so it's not just nfs3.
Kostas
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2006-11-15 at 18:31 -0800, Open Source wrote:
> Hi all,
>
> I think I have found the answer. It is similar to this issue but not
> exactly the same as:
>
> http://linux-nfs.org/pipermail/nfsv4/2005-November/002807.html
>
> Here's what is happening. In 2.6.18 there is a new file called
> fs/nfs/client.c. In this file it does the following for every new
> mount:
>
> 1) Lookup to see if an existing client has the same specification
> as the requested mount.
>
> 2) If so, clone that client. If not, create a new one.
>
> 3) Create any pipes required by the auth pseudoflavor by
> calling rpcauth_create.
>
> 4) Continue with the mounting of the volume.
>
> Now, if you have no connections to the server, a new rpc
> client is created and the pipes are created with no problems.
> For the second mount to the same server, the rpc client is
> cloned and has the same path in /var/lib/nfs/rpc_pipefs/nfs
> has the first connection. Therefore on step 3 the pipe creation
> fails in net/sunrpc/auth_gss/auth_gss.c. This causes the
> entire mount to fail.
Thanks for debugging this! I think the right thing to do here is just to
give the cloned clients their own rpc_pipefs directory. Can you see if
the following patch fixes your problem?
Cheers,
Trond
----------------------------------------------------
From: Trond Myklebust <[email protected]>
Date: 1163695047 -0500
SUNRPC: Give cloned RPC clients their own rpc_pipefs directory
Signed-off-by: Trond Myklebust <[email protected]>
---
include/linux/sunrpc/clnt.h | 1 +
net/sunrpc/clnt.c | 19 +++++++++++--------
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index f6d1d64..a1be89d 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -53,6 +53,7 @@ struct rpc_clnt {
struct dentry * cl_dentry; /* inode */
struct rpc_clnt * cl_parent; /* Points to parent of clones */
struct rpc_rtt cl_rtt_default;
+ struct rpc_program * cl_program;
char cl_inline_name[32];
};
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 587f3ec..4d269e5 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -141,6 +141,7 @@ static struct rpc_clnt * rpc_new_client(
clnt->cl_vers = version->number;
clnt->cl_stats = program->stats;
clnt->cl_metrics = rpc_alloc_iostats(clnt);
+ clnt->cl_program = program;
if (!xprt_bound(clnt->cl_xprt))
clnt->cl_autobind = 1;
@@ -252,6 +253,7 @@ struct rpc_clnt *
rpc_clone_client(struct rpc_clnt *clnt)
{
struct rpc_clnt *new;
+ int err;
new = kmalloc(sizeof(*new), GFP_KERNEL);
if (!new)
@@ -259,6 +261,11 @@ rpc_clone_client(struct rpc_clnt *clnt)
memcpy(new, clnt, sizeof(*new));
atomic_set(&new->cl_count, 1);
atomic_set(&new->cl_users, 0);
+ err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
+ if (err != 0) {
+ kfree(new);
+ return ERR_PTR(err);
+ }
new->cl_parent = clnt;
atomic_inc(&clnt->cl_count);
new->cl_xprt = xprt_get(clnt->cl_xprt);
@@ -266,8 +273,6 @@ rpc_clone_client(struct rpc_clnt *clnt)
new->cl_autobind = 0;
new->cl_oneshot = 0;
new->cl_dead = 0;
- if (!IS_ERR(new->cl_dentry))
- dget(new->cl_dentry);
rpc_init_rtt(&new->cl_rtt_default, clnt->cl_xprt->timeout.to_initval);
if (new->cl_auth)
atomic_inc(&new->cl_auth->au_count);
@@ -328,16 +333,14 @@ rpc_destroy_client(struct rpc_clnt *clnt
rpcauth_destroy(clnt->cl_auth);
clnt->cl_auth = NULL;
}
- if (clnt->cl_parent != clnt) {
- if (!IS_ERR(clnt->cl_dentry))
- dput(clnt->cl_dentry);
- rpc_destroy_client(clnt->cl_parent);
- goto out_free;
- }
if (!IS_ERR(clnt->cl_dentry)) {
rpc_rmdir(clnt->cl_dentry);
rpc_put_mount();
}
+ if (clnt->cl_parent != clnt) {
+ rpc_destroy_client(clnt->cl_parent);
+ goto out_free;
+ }
if (clnt->cl_server != clnt->cl_inline_name)
kfree(clnt->cl_server);
out_free:
I know this might be a dumb question but I'm
not able to apply the patch. How do I do this?
I cut and paste everything from the "diff --git"
line into a file.
Then I did: "patch -p1 < nfs_pipe_fix.patch"
while sitting in the root directory of my kernel source.
I get the following error:
patching file include/linux/sunrpc/clnt.h
patch: **** malformed patch at line 11: };
Please let me know what to do here.
Thanks,
Paarvai
----- Original Message ----
From: Trond Myklebust <[email protected]>
To: Open Source <[email protected]>
Cc: [email protected]; [email protected]
Sent: Thursday, November 16, 2006 9:46:04 AM
Subject: Re: "mount: File exists" when trying to mount a second krb5 volume!
On Wed, 2006-11-15 at 18:31 -0800, Open Source wrote:
> Hi all,
>
> I think I have found the answer. It is similar to this issue but not
> exactly the same as:
>
> http://linux-nfs.org/pipermail/nfsv4/2005-November/002807.html
>
> Here's what is happening. In 2.6.18 there is a new file called
> fs/nfs/client.c. In this file it does the following for every new
> mount:
>
> 1) Lookup to see if an existing client has the same specification
> as the requested mount.
>
> 2) If so, clone that client. If not, create a new one.
>
> 3) Create any pipes required by the auth pseudoflavor by
> calling rpcauth_create.
>
> 4) Continue with the mounting of the volume.
>
> Now, if you have no connections to the server, a new rpc
> client is created and the pipes are created with no problems.
> For the second mount to the same server, the rpc client is
> cloned and has the same path in /var/lib/nfs/rpc_pipefs/nfs
> has the first connection. Therefore on step 3 the pipe creation
> fails in net/sunrpc/auth_gss/auth_gss.c. This causes the
> entire mount to fail.
Thanks for debugging this! I think the right thing to do here is just to
give the cloned clients their own rpc_pipefs directory. Can you see if
the following patch fixes your problem?
Cheers,
Trond
----------------------------------------------------
From: Trond Myklebust <[email protected]>
Date: 1163695047 -0500
SUNRPC: Give cloned RPC clients their own rpc_pipefs directory
Signed-off-by: Trond Myklebust <[email protected]>
---
include/linux/sunrpc/clnt.h | 1 +
net/sunrpc/clnt.c | 19 +++++++++++--------
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index f6d1d64..a1be89d 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -53,6 +53,7 @@ struct rpc_clnt {
struct dentry * cl_dentry; /* inode */
struct rpc_clnt * cl_parent; /* Points to parent of clones */
struct rpc_rtt cl_rtt_default;
+ struct rpc_program * cl_program;
char cl_inline_name[32];
};
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 587f3ec..4d269e5 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -141,6 +141,7 @@ static struct rpc_clnt * rpc_new_client(
clnt->cl_vers = version->number;
clnt->cl_stats = program->stats;
clnt->cl_metrics = rpc_alloc_iostats(clnt);
+ clnt->cl_program = program;
if (!xprt_bound(clnt->cl_xprt))
clnt->cl_autobind = 1;
@@ -252,6 +253,7 @@ struct rpc_clnt *
rpc_clone_client(struct rpc_clnt *clnt)
{
struct rpc_clnt *new;
+ int err;
new = kmalloc(sizeof(*new), GFP_KERNEL);
if (!new)
@@ -259,6 +261,11 @@ rpc_clone_client(struct rpc_clnt *clnt)
memcpy(new, clnt, sizeof(*new));
atomic_set(&new->cl_count, 1);
atomic_set(&new->cl_users, 0);
+ err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
+ if (err != 0) {
+ kfree(new);
+ return ERR_PTR(err);
+ }
new->cl_parent = clnt;
atomic_inc(&clnt->cl_count);
new->cl_xprt = xprt_get(clnt->cl_xprt);
@@ -266,8 +273,6 @@ rpc_clone_client(struct rpc_clnt *clnt)
new->cl_autobind = 0;
new->cl_oneshot = 0;
new->cl_dead = 0;
- if (!IS_ERR(new->cl_dentry))
- dget(new->cl_dentry);
rpc_init_rtt(&new->cl_rtt_default, clnt->cl_xprt->timeout.to_initval);
if (new->cl_auth)
atomic_inc(&new->cl_auth->au_count);
@@ -328,16 +333,14 @@ rpc_destroy_client(struct rpc_clnt *clnt
rpcauth_destroy(clnt->cl_auth);
clnt->cl_auth = NULL;
}
- if (clnt->cl_parent != clnt) {
- if (!IS_ERR(clnt->cl_dentry))
- dput(clnt->cl_dentry);
- rpc_destroy_client(clnt->cl_parent);
- goto out_free;
- }
if (!IS_ERR(clnt->cl_dentry)) {
rpc_rmdir(clnt->cl_dentry);
rpc_put_mount();
}
+ if (clnt->cl_parent != clnt) {
+ rpc_destroy_client(clnt->cl_parent);
+ goto out_free;
+ }
if (clnt->cl_server != clnt->cl_inline_name)
kfree(clnt->cl_server);
out_free:
On Thu, 2006-11-16 at 12:50 -0800, Open Source wrote:
> I know this might be a dumb question but I'm
> not able to apply the patch. How do I do this?
>
> I cut and paste everything from the "diff --git"
> line into a file.
>
> Then I did: "patch -p1 < nfs_pipe_fix.patch"
> while sitting in the root directory of my kernel source.
>
> I get the following error:
>
> patching file include/linux/sunrpc/clnt.h
> patch: **** malformed patch at line 11: };
Don't cut n' paste, since that tends to mangle spaces, linefeed, etc.
Just save the entire message using your mail browser's 'save to file'
feature and feed the resulting file to 'patch -p1'.
Cheers,
Trond
Thanks Trond. Saving the patch did the trick. I had
to do some manual hacking to get the patch to
apply because you must have done your diff
against a different kernel tree revision. I'm using
2.6.18 from FC5 updates.
Once I massaged things, the patch compiled and it
works. I am able to mount more than one partition
with no problems now. However, I cannot speak
to the finer points (like memory leaks, etc.) since
I don't know the code so well. I trust someone else
will independently verify it (i.e., code review) before
it gets into the kernel tree.
So this brings me back to the question? Can we get
this is back into the main tree as soon as possible?
2.6.19 is on rc5. So ideally we could get it in there
soon. 2.6.18 has a .2 subsubrelease. So we could
also get it into the .3 version soon. Thoughts?
Thanks again,
Paarvai
----- Original Message ----
From: Trond Myklebust <[email protected]>
To: Open Source <[email protected]>
Cc: [email protected]; [email protected]
Sent: Thursday, November 16, 2006 12:55:54 PM
Subject: Re: "mount: File exists" when trying to mount a second krb5 volume!
On Thu, 2006-11-16 at 12:50 -0800, Open Source wrote:
> I know this might be a dumb question but I'm
> not able to apply the patch. How do I do this?
>
> I cut and paste everything from the "diff --git"
> line into a file.
>
> Then I did: "patch -p1 < nfs_pipe_fix.patch"
> while sitting in the root directory of my kernel source.
>
> I get the following error:
>
> patching file include/linux/sunrpc/clnt.h
> patch: **** malformed patch at line 11: };
Don't cut n' paste, since that tends to mangle spaces, linefeed, etc.
Just save the entire message using your mail browser's 'save to file'
feature and feed the resulting file to 'patch -p1'.
Cheers,
Trond
On Fri, Nov 17, 2006 at 11:59:25AM -0800, Open Source wrote:
> Thanks Trond. Saving the patch did the trick. I had
> to do some manual hacking to get the patch to
> apply because you must have done your diff
> against a different kernel tree revision. I'm using
> 2.6.18 from FC5 updates.
>
> Once I massaged things, the patch compiled and it
> works. I am able to mount more than one partition
> with no problems now. However, I cannot speak
> to the finer points (like memory leaks, etc.) since
> I don't know the code so well. I trust someone else
> will independently verify it (i.e., code review) before
> it gets into the kernel tree.
I did the same with the FC6 2.6.18 kernel and while it does allow
me to have more than one mount from the server autofs decides that
my home is not in use any more and it unmounts it, somehow this
causes the system to freeze as well.
Nov 17 16:28:14 thufir automount[2483]: mount still busy /home
Nov 17 16:29:29 thufir automount[2483]: expiring path /home/georgiou
Nov 17 16:29:29 thufir automount[2483]: unmounting dir = /home/georgiou
Nov 17 16:29:32 thufir automount[2483]: expired /home/georgiou
Here is the patch with my changes to apply in FC6 which most likely is
bad since I really don't know the code at all :(
Kostas Georgiou
diff -u a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -64,6 +64,7 @@
struct dentry * cl_dentry; /* inode */
struct rpc_clnt * cl_parent; /* Points to parent of clones */
struct rpc_rtt cl_rtt_default;
+ struct rpc_program * cl_program;
struct rpc_portmap cl_pmap_default;
char cl_inline_name[32];
};
diff -u a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -154,6 +154,7 @@
clnt->cl_prot = xprt->prot;
clnt->cl_stats = program->stats;
clnt->cl_metrics = rpc_alloc_iostats(clnt);
+ clnt->cl_program = program;
rpc_init_wait_queue(&clnt->cl_pmap_default.pm_bindwait, "bindwait");
if (!clnt->cl_port)
@@ -235,6 +236,7 @@
rpc_clone_client(struct rpc_clnt *clnt)
{
struct rpc_clnt *new;
+ int err;
new = kmalloc(sizeof(*new), GFP_KERNEL);
if (!new)
@@ -242,6 +244,11 @@
memcpy(new, clnt, sizeof(*new));
atomic_set(&new->cl_count, 1);
atomic_set(&new->cl_users, 0);
+ err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
+ if (err != 0) {
+ kfree(new);
+ return ERR_PTR(err);
+ }
new->cl_parent = clnt;
atomic_inc(&clnt->cl_count);
/* Duplicate portmapper */
@@ -250,8 +257,6 @@
new->cl_autobind = 0;
new->cl_oneshot = 0;
new->cl_dead = 0;
- if (!IS_ERR(new->cl_dentry))
- dget(new->cl_dentry);
rpc_init_rtt(&new->cl_rtt_default, clnt->cl_xprt->timeout.to_initval);
if (new->cl_auth)
atomic_inc(&new->cl_auth->au_count);
@@ -313,12 +318,6 @@
rpcauth_destroy(clnt->cl_auth);
clnt->cl_auth = NULL;
}
- if (clnt->cl_parent != clnt) {
- if (!IS_ERR(clnt->cl_dentry))
- dput(clnt->cl_dentry);
- rpc_destroy_client(clnt->cl_parent);
- goto out_free;
- }
if (!IS_ERR(clnt->cl_dentry)) {
rpc_rmdir(clnt->cl_dentry);
rpc_put_mount();
@@ -327,6 +326,10 @@
xprt_destroy(clnt->cl_xprt);
clnt->cl_xprt = NULL;
}
+ if (clnt->cl_parent != clnt) {
+ rpc_destroy_client(clnt->cl_parent);
+ goto out_free;
+ }
if (clnt->cl_server != clnt->cl_inline_name)
kfree(clnt->cl_server);
out_free:
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs