diff options
| author | J. Bruce Fields <bfields@fieldses.org> | 2006-01-03 09:55:44 +0100 |
|---|---|---|
| committer | Trond Myklebust <Trond.Myklebust@netapp.com> | 2006-01-06 14:58:53 -0500 |
| commit | 5996a298da43a03081e9ba2116983d173001c862 (patch) | |
| tree | 533a3289102051cc3e033eff5730301776e64d31 /fs/lockd | |
| parent | f232142cc21127c829559923eb405d1bcb2e2278 (diff) | |
| download | linux-5996a298da43a03081e9ba2116983d173001c862.tar.gz linux-5996a298da43a03081e9ba2116983d173001c862.tar.bz2 linux-5996a298da43a03081e9ba2116983d173001c862.zip | |
NLM: don't unlock on cancel requests
Currently when lockd gets an NLM_CANCEL request, it also does an unlock for
the same range. This is incorrect.
The Open Group documentation says that "This procedure cancels an
*outstanding* blocked lock request." (Emphasis mine.)
Also, consider a client that holds a lock on the first byte of a file, and
requests a lock on the entire file. If the client cancels that request
(perhaps because the requesting process is signalled), the server shouldn't
apply perform an unlock on the entire file, since that will also remove the
previous lock that the client was already granted.
Or consider a lock request that actually *downgraded* an exclusive lock to
a shared lock.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'fs/lockd')
| -rw-r--r-- | fs/lockd/svclock.c | 5 |
1 files changed, 0 insertions, 5 deletions
diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c index e42f0cc6c450..5fb48b4390bd 100644 --- a/fs/lockd/svclock.c +++ b/fs/lockd/svclock.c @@ -240,11 +240,6 @@ nlmsvc_delete_block(struct nlm_block *block, int unlock) nlmsvc_remove_block(block); if (fl->fl_next) posix_unblock_lock(file->f_file, fl); - if (unlock) { - fl->fl_type = F_UNLCK; - posix_lock_file(file->f_file, fl); - block->b_granted = 0; - } /* If the block is in the middle of a GRANT callback, * don't kill it yet. */ |