From: NeilBrown <neilb@cse.unsw.edu.au>
I can't see any reason for this file->f_count++. Removing it fixes a bug
which leaves an exported filesystem busy if a callback for a lock held on that
filesystem ever failed.
Found by Terence Rokop.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/fs/lockd/svclock.c | 1 -
1 files changed, 1 deletion(-)
diff -puN fs/lockd/svclock.c~nlm-fix-f_count-leak fs/lockd/svclock.c
--- 25/fs/lockd/svclock.c~nlm-fix-f_count-leak 2005-03-21 22:49:46.000000000 -0800
+++ 25-akpm/fs/lockd/svclock.c 2005-03-21 22:49:46.000000000 -0800
@@ -641,7 +641,6 @@ nlmsvc_grant_reply(struct svc_rqst *rqst
} else {
/* Lock is now held by client, or has been rejected.
* In both cases, the block should be removed. */
- file->f_count++;
up(&file->f_sema);
if (status == NLM_LCK_GRANTED)
nlmsvc_delete_block(block, 0);
_