lockd: send correct lock when granting a delayed lock.
authorNeilBrown <neilb@suse.de>
Fri, 7 Feb 2014 06:10:26 +0000 (17:10 +1100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 22 Feb 2014 20:41:27 +0000 (12:41 -0800)
commit5de64260830aafce062b99e17cb3963ecc4291bf
tree5b4900d1f9f6bec91dcce57efe532b9ef3b8eebd
parent600b64afd789d3d0deaf467b5fd88bca8d459768
lockd: send correct lock when granting a delayed lock.

commit 2ec197db1a56c9269d75e965f14c344b58b2a4f6 upstream.

If an NFS client attempts to get a lock (using NLM) and the lock is
not available, the server will remember the request and when the lock
becomes available it will send a GRANT request to the client to
provide the lock.

If the client already held an adjacent lock, the GRANT callback will
report the union of the existing and new locks, which can confuse the
client.

This happens because __posix_lock_file (called by vfs_lock_file)
updates the passed-in file_lock structure when adjacent or
over-lapping locks are found.

To avoid this problem we take a copy of the two fields that can
be changed (fl_start and fl_end) before the call and restore them
afterwards.
An alternate would be to allocate a 'struct file_lock', initialise it,
use locks_copy_lock() to take a copy, then locks_release_private()
after the vfs_lock_file() call.  But that is a lot more work.

Reported-by: Olaf Kirch <okir@suse.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

--
v1 had a couple of issues (large on-stack struct and didn't really work properly).
This version is much better tested.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
fs/lockd/svclock.c