summaryrefslogtreecommitdiffstats
path: root/fs/lockd
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2006-10-02 02:17:53 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-10-02 07:57:18 -0700
commit4a3ae42dc312dbdffee803efaf393421b79f997a (patch)
treed18249c89fc1a5ab273beec1639cde769a0b6e96 /fs/lockd
parent7dcf91ec6698fe8564ad91bbe42740aacaa0d9ee (diff)
downloadkernel-crypto-4a3ae42dc312dbdffee803efaf393421b79f997a.tar.gz
kernel-crypto-4a3ae42dc312dbdffee803efaf393421b79f997a.tar.xz
kernel-crypto-4a3ae42dc312dbdffee803efaf393421b79f997a.zip
[PATCH] knfsd: Correctly handle error condition from lockd_up
If lockd_up fails - what should we expect? Do we have to later call lockd_down? Well the nfs client thinks "no", the nfs server thinks "yes". lockd thinks "yes". The only answer that really makes sense is "no" !! So: Make lockd_up only increment nlmsvc_users on success. Make nfsd handle errors from lockd_up properly. Make sure lockd_up(0) never fails when lockd is running so that the 'reclaimer' call to lockd_up doesn't need to be error checked. Cc: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/lockd')
-rw-r--r--fs/lockd/clntlock.c2
-rw-r--r--fs/lockd/svc.c12
2 files changed, 6 insertions, 8 deletions
diff --git a/fs/lockd/clntlock.c b/fs/lockd/clntlock.c
index 6abb465b650..87e1d03e826 100644
--- a/fs/lockd/clntlock.c
+++ b/fs/lockd/clntlock.c
@@ -202,7 +202,7 @@ reclaimer(void *ptr)
/* This one ensures that our parent doesn't terminate while the
* reclaim is in progress */
lock_kernel();
- lockd_up(0);
+ lockd_up(0); /* note: this cannot fail as lockd is already running */
nlmclnt_prepare_reclaim(host);
/* First, reclaim all locks that have been marked. */
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 448768b5291..3cc369e5693 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -254,15 +254,11 @@ lockd_up(int proto) /* Maybe add a 'family' option when IPv6 is supported ?? */
mutex_lock(&nlmsvc_mutex);
/*
- * Unconditionally increment the user count ... this is
- * the number of clients who _want_ a lockd process.
- */
- nlmsvc_users++;
- /*
* Check whether we're already up and running.
*/
if (nlmsvc_pid) {
- error = make_socks(nlmsvc_serv, proto);
+ if (proto)
+ error = make_socks(nlmsvc_serv, proto);
goto out;
}
@@ -270,7 +266,7 @@ lockd_up(int proto) /* Maybe add a 'family' option when IPv6 is supported ?? */
* Sanity check: if there's no pid,
* we should be the first user ...
*/
- if (nlmsvc_users > 1)
+ if (nlmsvc_users)
printk(KERN_WARNING
"lockd_up: no pid, %d users??\n", nlmsvc_users);
@@ -302,6 +298,8 @@ lockd_up(int proto) /* Maybe add a 'family' option when IPv6 is supported ?? */
destroy_and_out:
svc_destroy(serv);
out:
+ if (!error)
+ nlmsvc_users++;
mutex_unlock(&nlmsvc_mutex);
return error;
}