<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/fs/lockd, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/fs/lockd?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/fs/lockd?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-09-26T18:02:42Z</updated>
<entry>
<title>SUNRPC: Parametrize how much of argsize should be zeroed</title>
<updated>2022-09-26T18:02:42Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2022-09-12T21:22:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=103cc1fafee48adb91fca0e19deb869fd23e46ab'/>
<id>urn:sha1:103cc1fafee48adb91fca0e19deb869fd23e46ab</id>
<content type='text'>
Currently, SUNRPC clears the whole of .pc_argsize before processing
each incoming RPC transaction. Add an extra parameter to struct
svc_procedure to enable upper layers to reduce the amount of each
operation's argument structure that is zeroed by SUNRPC.

The size of struct nfsd4_compoundargs, in particular, is a lot to
clear on each incoming RPC Call. A subsequent patch will cut this
down to something closer to what NFSv2 and NFSv3 uses.

This patch should cause no behavior changes.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>lockd: move from strlcpy with unused retval to strscpy</title>
<updated>2022-09-26T18:02:20Z</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2022-08-18T21:01:16Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=97f8e62572555f8ad578d7b1739ba64d5d2cac0f'/>
<id>urn:sha1:97f8e62572555f8ad578d7b1739ba64d5d2cac0f</id>
<content type='text'>
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>lockd: detect and reject lock arguments that overflow</title>
<updated>2022-08-04T14:28:48Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2022-08-01T19:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde'/>
<id>urn:sha1:6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde</id>
<content type='text'>
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 &lt;j.kasiak@gmail.com&gt;
Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.14+
</content>
</entry>
<entry>
<title>NLM: Defend against file_lock changes after vfs_test_lock()</title>
<updated>2022-07-30T00:08:56Z</updated>
<author>
<name>Benjamin Coddington</name>
<email>bcodding@redhat.com</email>
</author>
<published>2022-06-13T13:40:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=184cefbe62627730c30282df12bcff9aae4816ea'/>
<id>urn:sha1:184cefbe62627730c30282df12bcff9aae4816ea</id>
<content type='text'>
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 &lt;rbergant@redhat.com&gt;
Tested-by: Roberto Bergantinos Corpas &lt;rbergant@redhat.com&gt;
Signed-off-by: Benjamin Coddington &lt;bcodding@redhat.com&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>lockd: fix nlm_close_files</title>
<updated>2022-07-11T19:49:56Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2022-07-11T18:30:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1197eb5906a5464dbaea24cac296dfc38499cc00'/>
<id>urn:sha1:1197eb5906a5464dbaea24cac296dfc38499cc00</id>
<content type='text'>
This loop condition tries a bit too hard to be clever. Just test for
the two indices we care about explicitly.

Cc: J. Bruce Fields &lt;bfields@fieldses.org&gt;
Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file")
Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>lockd: set fl_owner when unlocking files</title>
<updated>2022-07-11T19:49:56Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2022-07-11T18:30:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=aec158242b87a43d83322e99bc71ab4428e5ab79'/>
<id>urn:sha1:aec158242b87a43d83322e99bc71ab4428e5ab79</id>
<content type='text'>
Unlocking a POSIX lock on an inode with vfs_lock_file only works if
the owner matches. Ensure we set it in the request.

Cc: J. Bruce Fields &lt;bfields@fieldses.org&gt;
Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file")
Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>NFSD: Move svc_serv_ops::svo_function into struct svc_serv</title>
<updated>2022-02-28T15:26:40Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2022-02-16T17:16:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=37902c6313090235c847af89c5515591261ee338'/>
<id>urn:sha1:37902c6313090235c847af89c5515591261ee338</id>
<content type='text'>
Hoist svo_function back into svc_serv and remove struct
svc_serv_ops, since the struct is now devoid of fields.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>NFSD: Remove svc_serv_ops::svo_module</title>
<updated>2022-02-28T15:26:40Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2022-02-16T17:31:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f49169c97fceb21ad6a0aaf671c50b0f520f15a5'/>
<id>urn:sha1:f49169c97fceb21ad6a0aaf671c50b0f520f15a5</id>
<content type='text'>
struct svc_serv_ops is about to be removed.

Neil Brown says:
&gt; I suspect svo_module can go as well - I don't think the thread is
&gt; ever the thing that primarily keeps a module active.

A random sample of kthread_create() callers shows sunrpc is the only
one that manages module reference count in this way.

Suggested-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>SUNRPC: Remove svc_shutdown_net()</title>
<updated>2022-02-28T15:26:40Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2022-01-26T16:30:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c7d7ec8f043e53ad16e30f5ebb8b9df415ec0f2b'/>
<id>urn:sha1:c7d7ec8f043e53ad16e30f5ebb8b9df415ec0f2b</id>
<content type='text'>
Clean up: svc_shutdown_net() now does nothing but call
svc_close_net(). Replace all external call sites.

svc_close_net() is renamed to be the inverse of svc_xprt_create().

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>SUNRPC: Rename svc_create_xprt()</title>
<updated>2022-02-28T15:26:39Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2022-01-26T16:42:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=352ad31448fecc78a2e9b78da64eea5d63b8d0ce'/>
<id>urn:sha1:352ad31448fecc78a2e9b78da64eea5d63b8d0ce</id>
<content type='text'>
Clean up: Use the "svc_xprt_&lt;task&gt;" function naming convention as
is used for other external APIs.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
</feed>
