J. Bruce Fields 40595cdc93 nfs: block notification on fs with its own ->lock ... 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 f657f8eef3 ("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 f657f8eef3 ("nfs: don't atempt blocking locks on nfs reexports") [sic] and commit b840be2f00 ("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 <vvs@virtuozzo.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> [ cel: Description rewritten to address checkpatch nits ] [ cel: Fixed warning when SUNRPC debugging is disabled ] [ cel: Fixed NULL check ] Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Vasily Averin <vvs@virtuozzo.com>		2022-01-08 14:42:01 -05:00
..
bind.h	Keep read and write fds with each nlm_file	2021-08-23 18:05:31 -04:00
debug.h	…
lockd.h	nfs: block notification on fs with its own ->lock	2022-01-08 14:42:01 -05:00
nlm.h	…
share.h	…
xdr.h	SUNRPC: Change return value type of .pc_encode	2021-10-13 11:34:49 -04:00
xdr4.h	SUNRPC: Change return value type of .pc_encode	2021-10-13 11:34:49 -04:00