linux.git/fs/lockd/svclock.c, branch v6.5

lockd: server should unlock lock if client rejects the grant

2023-04-26T13:05:00+00:00

Currently lockd just dequeues the block and ignores it if the client
sends a GRANT_RES with a status of nlm_lck_denied. That status is an
indicator that the client has rejected the lock, so the right thing to
do is to unlock the lock we were trying to grant.

Reported-by: Yongcheng Yang 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2063818
Signed-off-by: Jeff Layton 
Signed-off-by: Chuck Lever

lockd: fix file selection in nlmsvc_cancel_blocked

2022-12-10T16:01:11+00:00

We currently do a lock_to_openmode call based on the arguments from the
NLM_UNLOCK call, but that will always set the fl_type of the lock to
F_UNLCK, and the O_RDONLY descriptor is always chosen.

Fix it to use the file_lock from the block instead.

Signed-off-by: Jeff Layton 
Signed-off-by: Chuck Lever

lockd: ensure we use the correct file descriptor when unlocking

2022-12-10T16:01:11+00:00

Shared locks are set on O_RDONLY descriptors and exclusive locks are set
on O_WRONLY ones. nlmsvc_unlock however calls vfs_lock_file twice, once
for each descriptor, but it doesn't reset fl_file. Ensure that it does.

Signed-off-by: Jeff Layton 
Signed-off-by: Chuck Lever

NLM: Defend against file_lock changes after vfs_test_lock()

2022-07-30T00:08:56+00:00

Instead of trusting that struct file_lock returns completely unchanged
after vfs_test_lock() when there's no conflicting lock, stash away our
nlm_lockowner reference so we can properly release it for all cases.

This defends against another file_lock implementation overwriting fl_owner
when the return type is F_UNLCK.

Reported-by: Roberto Bergantinos Corpas 
Tested-by: Roberto Bergantinos Corpas 
Signed-off-by: Benjamin Coddington 
Signed-off-by: Chuck Lever

nfs: block notification on fs with its own ->lock

2022-01-08T19:42:01+00:00

NFSv4.1 supports an optional lock notification feature which notifies
the client when a lock comes available.  (Normally NFSv4 clients just
poll for locks if necessary.)  To make that work, we need to request a
blocking lock from the filesystem.

We turned that off for NFS in commit f657f8eef3ff ("nfs: don't atempt
blocking locks on nfs reexports") [sic] because it actually blocks the
nfsd thread while waiting for the lock.

Thanks to Vasily Averin for pointing out that NFS isn't the only
filesystem with that problem.

Any filesystem that leaves ->lock NULL will use posix_lock_file(), which
does the right thing.  Simplest is just to assume that any filesystem
that defines its own ->lock is not safe to request a blocking lock from.

So, this patch mostly reverts commit f657f8eef3ff ("nfs: don't atempt
blocking locks on nfs reexports") [sic] and commit b840be2f00c0 ("lockd:
don't attempt blocking locks on nfs reexports"), and instead uses a
check of ->lock (Vasily's suggestion) to decide whether to support
blocking lock notifications on a given filesystem.  Also add a little
documentation.

Perhaps someday we could add back an export flag later to allow
filesystems with "good" ->lock methods to support blocking lock
notifications.

Reported-by: Vasily Averin 
Signed-off-by: J. Bruce Fields 
[ cel: Description rewritten to address checkpatch nits ]
[ cel: Fixed warning when SUNRPC debugging is disabled ]
[ cel: Fixed NULL check ]
Signed-off-by: Chuck Lever 
Reviewed-by: Vasily Averin

lockd: don't attempt blocking locks on nfs reexports

2021-08-26T19:32:18+00:00

As in the v4 case, it doesn't work well to block waiting for a lock on
an nfs filesystem.

As in the v4 case, that means we're depending on the client to poll.
It's probably incorrect to depend on that, but I *think* clients do poll
in practice.  In any case, it's an improvement over hanging the lockd
thread indefinitely as we currently are.

Signed-off-by: J. Bruce Fields 
Acked-by: Anna Schumaker 
Signed-off-by: Chuck Lever

Keep read and write fds with each nlm_file

2021-08-23T22:05:31+00:00

We shouldn't really be using a read-only file descriptor to take a write
lock.

Most filesystems will put up with it.  But NFS, for example, won't.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Chuck Lever

nlm: minor refactoring

2021-08-23T16:56:17+00:00

Make this lookup slightly more concise, and prepare for changing how we
look this up in a following patch.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Chuck Lever

lockd: lockd server-side shouldn't set fl_ops

2021-08-21T15:48:34+00:00

Locks have two sets of op arrays, fl_lmops for the lock manager (lockd
or nfsd), fl_ops for the filesystem.  The server-side lockd code has
been setting its own fl_ops, which leads to confusion (and crashes) in
the reexport case, where the filesystem expects to be the only one
setting fl_ops.

And there's no reason for it that I can see-the lm_get/put_owner ops do
the same job.

Reported-by: Daire Byrne 
Tested-by: Daire Byrne 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Chuck Lever

lockd: Fix invalid lockowner cast after vfs_test_lock

2021-08-17T15:47:52+00:00

After calling vfs_test_lock() the pointer to a conflicting lock can be
returned, and that lock is not guarunteed to be owned by nlm.  In that
case, we cannot cast it to struct nlm_lockowner.  Instead return the pid
of that conflicting lock.

Fixes: 646d73e91b42 ("lockd: Show pid of lockd for remote locks")
Signed-off-by: Benjamin Coddington 
Signed-off-by: Chuck Lever