Bug 215383

kernel export threads (nfsd/lockd/ksmbd) cannot process blocking locks synchronously: they have limited number of worker threads and if all of them will wait on blocking lock server will unable to handle other requests and can deadlock.
To avoid this problem these servers forces vfs_lock_file to return asynchronously():
 * Callers expecting ->lock() to return asynchronously
 * will only use F_SETLK, not F_SETLKW; they will set FL_SLEEP if (and only if)
 * the request is for a blocking lock.
 (from comment above vfs_lock_file())

by the other words, to correctly handle blocking lock requests:
a) servers should use F_SETLK with FL_SLEEP
b) ->lock() file system functions should handle such request correctly.

At present (v5.15) this does not happen in some cases:
- on server side: ksmbd still use F_SETLKW (patch sent already)
- file systems defined own ->lock function in most cases does not expect such requests and handles them incorrectly, can block them and cause export threads to deadlock.

To temporally work around this problem kernel threads will drop FL_SLEEP flag if exported file system defines own -> lock function (according patches are sent already). (file system without own ->lock() function uses safe posix_lock_file())

This bug is required to track fixes in all affected file systems. When this task will be done, work around dropped FL_SLEEP in kernel threads can be reverted.

Below is list of affected in-tree file systems, with noticed issues:

- fuse:
 fuse_setlk() ignores F_SETLK cmd, handles FL_SLEEP flag and call blocking
 FUSE_SETLKW.

(One more problem is that kernel part of FUSE cannot guarantee that
 user space handles such requests correctly. On the other hand any other
 remote file system depends on reply of server side, that potentially 
 can handle non-blocking requests incorrectly, so I think we can hope for
 the best and ignore this problem)

- afs:
 afs_do_setlk() ignores F_SETLK cmd but handles FL_SLEEP,
 uses blocking locks_lock_file_wait

- cifs:
 cifs_lock ignores F_SETLK cmd, handles FL_SLEEP flag and set up wait_flag
 forced cifs_setlk() to submit blocking requests.
 (then it executes potentially blocking locks_lock_file_wait(), 
  but it looks safe, see commend about dlm_posix_lock below)

- v9fs:
 v9fs_file_do_lock() uses blocking locks_lock_file_wait()

- nfs:
 do_setlk() uses blocking locks_lock_file_wait()
 _nfs4_proc_setlk uses blocking locks_lock_file_wait()

- gfs2 and ocfs:
 uses dlm_posix_lock() that calls locks_lock_file_wait() after
 successfully finished remote request. However in this situation this
 looks safe.

- orangefs:
- ceph:
  looks safe