man: document io-wq handling of file system managed locks

The kernel side no longer fails lock requests on files with their own
->flock()/->lock() handling (NFS, FUSE, etc) with -EOPNOTSUPP, instead
they are handled via the io_uring async worker pool. Update the
io_uring_prep_flock and io_uring_prep_ofd_lock man pages accordingly:
document the worker occupancy caveat for contended waits, replace the
-EOPNOTSUPP error with -EINTR for signal-interrupted waits, and scope
the "no deadlock detection" statement to generic VFS locks, as a file
system may implement its own.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Author: axboe

man/io_uring_prep_flock.3

@@ -71,10 +71,14 @@ of the same file does not), and the lock is released on
 or once every file descriptor referring to the open file description has
 been closed.
 .PP
-Only locks managed by the generic VFS locking code are supported. If the
-file resides on a file system that implements its own flock handling, such
-as NFS, the request fails with
-.BR -EOPNOTSUPP .
+If the file resides on a file system that implements its own flock
+handling, such as NFS or FUSE, the request is handled by the io_uring
+async worker pool instead, as even a non-blocking attempt may have to
+communicate with a lock server. Such requests behave identically, with
+the caveat that each pending request occupies a worker thread for as long
+as it waits for a contended lock. If the wait is interrupted by a signal,
+the request completes with
+.BR -EINTR .
 .PP
 Available since kernel 7.3.
 
@@ -108,16 +112,15 @@ not opened for reading or writing.
 .B -ECANCELED
 The request was cancelled before the lock was acquired.
 .TP
+.B -EINTR
+The wait for a file system managed lock was interrupted by a signal.
+.TP
 .B -EINVAL
 .I flock_op
 is not valid, or stray submission queue entry fields were set.
 .TP
 .B -ENOLCK
 The kernel ran out of memory for allocating lock records.
-.TP
-.B -EOPNOTSUPP
-The file has a file system specific flock implementation, which is not
-supported.
 .SH NOTES
 io_uring does not support passing in a timeout for the request. Instead,
 applications are encouraged to use a linked timeout to abort the lock

man/io_uring_prep_ofd_lock.3

@@ -100,15 +100,21 @@ and negative lengths are not supported.
 .PP
 As with
 .BR F_OFD_SETLKW ,
-lock acquisitions are not subject to deadlock detection, a request will
-never fail with
+lock acquisitions on locks managed by the generic VFS locking code are not
+subject to deadlock detection, a request will never fail with
 .BR -EDEADLK .
 A request that can never be satisfied remains pending until cancelled.
 .PP
-Only locks managed by the generic VFS locking code are supported. If the
-file resides on a file system that implements its own locking, such as NFS,
-the request fails with
-.BR -EOPNOTSUPP .
+If the file resides on a file system that implements its own locking, such
+as NFS or FUSE, the request is handled by the io_uring async worker pool
+instead, as even a non-blocking attempt may have to communicate with a
+lock server. Such requests behave like the file system's
+.BR fcntl (2)
+locking does - including any deadlock detection it may implement - with
+the caveat that each pending request occupies a worker thread for as long
+as it waits for a contended lock. If the wait is interrupted by a signal,
+the request completes with
+.BR -EINTR .
 .PP
 Available since kernel 7.3.
 
@@ -145,6 +151,9 @@ on one not open for writing.
 .B -ECANCELED
 The request was cancelled before the lock was acquired.
 .TP
+.B -EINTR
+The wait for a file system managed lock was interrupted by a signal.
+.TP
 .B -EINVAL
 .I type
 or
@@ -156,10 +165,6 @@ exceeds the maximum file offset.
 .B -ENOLCK
 The kernel ran out of memory for allocating lock records.
 .TP
-.B -EOPNOTSUPP
-The file has a file system specific lock implementation, which is not
-supported.
-.TP
 .B -EOVERFLOW
 .I start
 plus