linux-toradex.git/include/linux/lockd, branch v6.0-rc1

lockd: detect and reject lock arguments that overflow

2022-08-04T14:28:48+00:00

lockd doesn't currently vet the start and length in nlm4 requests like
it should, and can end up generating lock requests with arguments that
overflow when passed to the filesystem.

The NLM4 protocol uses unsigned 64-bit arguments for both start and
length, whereas struct file_lock tracks the start and end as loff_t
values. By the time we get around to calling nlm4svc_retrieve_args,
we've lost the information that would allow us to determine if there was
an overflow.

Start tracking the actual start and len for NLM4 requests in the
nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they
won't cause an overflow, and return NLM4_FBIG if they do.

Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=392
Reported-by: Jan Kasiak 
Signed-off-by: Jeff Layton 
Signed-off-by: Chuck Lever 
Cc:  # 5.14+

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

SUNRPC: Change return value type of .pc_encode

2021-10-13T15:34:49+00:00

Returning an undecorated integer is an age-old trope, but it's
not clear (even to previous experts in this code) that the only
valid return values are 1 and 0. These functions do not return
a negative errno, rpc_stat value, or a positive length.

Document there are only two valid return values by having
.pc_encode return only true or false.

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

SUNRPC: Replace the "__be32 *p" parameter to .pc_encode

2021-10-13T15:34:49+00:00

The passed-in value of the "__be32 *p" parameter is now unused in
every server-side XDR encoder, and can be removed.

Note also that there is a line in each encoder that sets up a local
pointer to a struct xdr_stream. Passing that pointer from the
dispatcher instead saves one line per encoder function.

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

SUNRPC: Change return value type of .pc_decode

2021-10-13T14:29:41+00:00

Returning an undecorated integer is an age-old trope, but it's
not clear (even to previous experts in this code) that the only
valid return values are 1 and 0. These functions do not return
a negative errno, rpc_stat value, or a positive length.

Document there are only two valid return values by having
.pc_decode return only true or false.

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

SUNRPC: Replace the "__be32 *p" parameter to .pc_decode

2021-10-13T14:29:41+00:00

The passed-in value of the "__be32 *p" parameter is now unused in
every server-side XDR decoder, and can be removed.

Note also that there is a line in each decoder that sets up a local
pointer to a struct xdr_stream. Passing that pointer from the
dispatcher instead saves one line per decoder function.

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

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 nlm_lookup_file argument change

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

It'll come in handy to get the whole nlm_lock.

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

lockd: Remove stale comments

2021-07-07T00:14:42+00:00

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