(xprt, struct svc_sock, sk_xprt);
> - struct page_frag_cache *pfc = &svsk->sk_frag_cache;
> struct socket *sock = svsk->sk_sock;
>
> trace_svcsock_free(svsk, sock);
> @@ -1619,8 +1618,7 @@ static void svc_sock_free(struct svc_xprt *xprt)
> sockfd_put(sock);
> else
> sock_release(sock);
> - if (pfc->va)
> - __page_frag_cache_drain(virt_to_head_page(pfc->va),
> - pfc->pagecnt_bias);
> +
> + page_frag_cache_drain(&svsk->sk_frag_cache);
> kfree(svsk);
> }
> --
> 2.33.0
>
--
Chuck Lever
onding API mirroring the page_pool_alloc_va()
> API of the page_pool. So that callers expecting to deal with
> va, page or both va and page may call page_frag_alloc_va*,
> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsh
On Wed, Apr 10, 2024 at 01:07:41PM -0400, Steven Rostedt wrote:
> On Wed, 10 Apr 2024 12:38:53 -0400
> Chuck Lever wrote:
>
> > On Wed, Apr 10, 2024 at 12:38:13PM -0400, Steven Rostedt wrote:
> > > From: "Steven Rostedt (Google)"
> > >
> > >
tuality, commit c1fa617caeb0 ("tracing:
> Rework __assign_str() and __string() to not duplicate getting the string")
> is the commit that makes __string_str_len() obsolete).
>
> Cc: sta...@vger.kernel.org
> Fixes: 0c77668ddb4e7 ("SUNRPC: Introduce trace points in
verifier, NFS4_VERIFIER_SIZE)
> - __string_len(name, name, clp->cl_name.len)
> + __string_len(name, clp->cl_name.data, clp->cl_name.len)
> ),
> TP_fast_assign(
> __entry->cl_boot = clp->cl_clientid.cl_boot;
> --
> 2.43.0
>
Do you want me to take this through the nfsd tree, or would you like
an Ack from me so you can handle it as part of your clean up? Just
in case:
Acked-by: Chuck Lever
--
Chuck Lever
't seem to be benefit for API consumers to have to
understand the internal structure of struct file_lock/lease to reach
into fl_core. Having accessor functions for common fields like
fl_type and fl_flags could be cleaner.
For the series:
Reviewed-by: Chuck Lever
For the nfsd and lockd parts:
on
For the changes in fs/lockd/ and fs/nfsd/:
Acked-by: Chuck Lever
> ---
> fs/ceph/locks.c | 8 ++---
> fs/lockd/clnt4xdr.c | 8 ++---
> fs/lockd/clntproc.c | 6 ++--
> fs/lockd/clntxdr.c | 8 ++---
> fs/lockd/svc4proc
| 74 ++--
> fs/smb/client/smb2file.c| 2 +-
> fs/smb/server/smb2pdu.c | 44 +--
> fs/smb/server/vfs.c | 14 +-
> include/linux/filelock.h| 58 ++-
> include/linux/fs.h | 5 +-
> include/linux/lockd/lockd.h | 8 +-
> include/trace/events/afs.h | 4 +-
> include/trace/events/filelock.h | 54 +--
> 48 files changed, 1119 insertions(+), 825 deletions(-)
> ---
> base-commit: 052d534373b7ed33712a63d5e17b2b6cdbce84fd
> change-id: 20240116-flsplit-bdb46824db68
>
> Best regards,
> --
> Jeff Layton
>
--
Chuck Lever
ckd/lockd.h, fs/lockd/, and
fs/nfsd/:
Acked-by: Chuck Lever
> ---
> fs/9p/vfs_file.c| 38 ++---
> fs/afs/flock.c | 55 +++---
> fs/ceph/locks.c | 66 +++
> fs/dlm/plock.c | 44 ++---
> fs/fuse/file.c
16:46, Gustavo A. R. Silva wrote:
>> On Fri, Nov 20, 2020 at 01:27:51PM -0500, Chuck Lever wrote:
>>>
>>>
>>>> On Nov 20, 2020, at 1:26 PM, Gustavo A. R. Silva
>>>> wrote:
>>>>
>>>> In preparation to enable -Wimplicit-fallt
- u64 end;
> -
> - end = start + len;
> - return end >= start ? end: NFS4_MAX_UINT64;
> -}
> -
> /* last octet in a range */
> static inline u64
> last_byte_offset(u64 start, u64 len)
> --
> 1.8.3.1
>
--
Chuck Lever
> On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
>
> On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
>> On Mon, Apr 05, 2021 at 11:42:31PM +0000, Chuck Lever III wrote:
>>
>>> We need to get a better idea what correctness testing has been done,
>>> a
d_drc_mem_used = 0;
> - spin_lock_init(&nfsd_drc_lock);
> dprintk("%s nfsd_drc_max_mem %lu \n", __func__, nfsd_drc_max_mem);
> }
>
>
--
Chuck Lever
ap_update(struct cache_detail *cd, struct ip_map *ipm,
> struct unix_domain *udom, time64_t expiry)
> {
> --
> 1.8.3.1
>
--
Chuck Lever
63,6 @@ static void set_max_drc(void)
> nfsd_drc_max_mem = (nr_free_buffer_pages()
> >> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE;
> nfsd_drc_mem_used = 0;
> - spin_lock_init(&nfsd_drc_lock);
> dprintk("%s nfsd_drc_max_mem %lu \n", __func__, nfsd_drc_max_mem);
> }
>
>
--
Chuck Lever
correctness testing has been done,
and whether positive correctness testing results can be replicated
on a variety of platforms.
I have an old Haswell dual-socket system in my lab, but otherwise
I'm not sure I have a platform that would be interesting for such a
test.
> AMD dual socket systems are well known to benefit from relaxed
> ordering, people have been doing this in userspace for a while now
> with the opt in.
--
Chuck Lever
Sorry for the reply via gmail, the original patch did not show up in
my Oracle mailbox.
I've been waiting for a resolution of this thread (and perhaps a
Reviewed-by). But in
the meantime I've committed this, provisionally, to the for-next topic branch in
git://git.kernel.org/pub/scm/linux/kernel/
> On Mar 23, 2021, at 3:56 PM, Mel Gorman wrote:
>
> On Tue, Mar 23, 2021 at 11:10:05AM -0400, Chuck Lever wrote:
>> Reduce the rate at which nfsd threads hammer on the page allocator.
>> This improves throughput scalability by enabling the threads to run
>> more
@@ int __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
>
> local_irq_restore(flags);
>
> - /* Prep pages with IRQs enabled. */
> - if (page_list) {
> - list_for_each_entry(page, page_list, lru)
> - prep_new_page(page, 0, gfp, 0);
> - } else {
> - while (prep_index < nr_populated)
> - prep_new_page(page_array[prep_index++], 0, gfp, 0);
> -
> - /*
> - * If the array is sparse, check whether the array is
> - * now fully populated. Continue allocations if
> - * necessary.
> - */
> - while (nr_populated < nr_pages && page_array[nr_populated])
> - nr_populated++;
> - if (hole && nr_populated < nr_pages)
> - goto retry_hole;
> - }
> -
> return nr_populated;
>
> failed_irq:
>
> --
> Mel Gorman
> SUSE Labs
--
Chuck Lever
Reduce the rate at which nfsd threads hammer on the page allocator.
This improves throughput scalability by enabling the threads to run
more independently of each other.
Signed-off-by: Chuck Lever
---
net/sunrpc/svc_xprt.c | 33 +
1 file changed, 17 insertions
sd_splice_actor()
by commit cf8208d0eabd ("sendfile: convert nfsd to
splice_direct_to_actor()").
Signed-off-by: Chuck Lever
---
net/sunrpc/svc_xprt.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 3cdd71a8
t superior to the list-based API.
---
Chuck Lever (2):
SUNRPC: Set rq_page_end differently
SUNRPC: Refresh rq_pages using a bulk page allocator
net/sunrpc/svc_xprt.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
--
Chuck Lever
> On Mar 22, 2021, at 3:49 PM, Mel Gorman wrote:
>
> On Mon, Mar 22, 2021 at 06:25:03PM +0000, Chuck Lever III wrote:
>>
>>
>>> On Mar 22, 2021, at 5:18 AM, Mel Gorman wrote:
>>>
>>> This series is based on top of Matthew Wilcox's se
rformance gains/losses in the changelogs.
>
> Patch 1 renames a variable name that is particularly unpopular
>
> Patch 2 adds a bulk page allocator
>
> Patch 3 adds an array-based version of the bulk allocator
>
> include/linux/gfp.h | 18 +
> mm/page_alloc.c | 171 ++--
> 2 files changed, 185 insertions(+), 4 deletions(-)
>
> --
> 2.26.2
>
--
Chuck Lever
> On Mar 19, 2021, at 6:08 PM, J. Bruce Fields wrote:
>
> On Fri, Mar 19, 2021 at 02:58:14PM +0000, Chuck Lever III wrote:
>> Hi Chris-
>>
>>> On Mar 19, 2021, at 10:54 AM, Chris Down wrote:
>>>
>>> The reclen is taken directly from the firs
, it
> seems reasonable to put this here since this particular code path is the
> one that has repeatedly come up in production.
>
> Signed-off-by: Chris Down
> Cc: Chuck Lever
> Cc: J. Bruce Fields
> Cc: Trond Myklebust
> Cc: David S. Miller
> ---
> net/sunrpc/svc
> On Mar 14, 2021, at 8:52 AM, Mel Gorman wrote:
>
> On Sat, Mar 13, 2021 at 07:33:43PM +, Matthew Wilcox wrote:
>> On Sat, Mar 13, 2021 at 04:56:31PM +0000, Chuck Lever III wrote:
>>> IME lists are indeed less CPU-efficient, but I wonder if that
>>> exp
We have, for instance, release_pages(), which is
an array-centric page allocator API. Maybe a helper function or two
might prevent duplication of the list conversion logic.
And I agree with Mel that passing a single large array seems more
useful then having to build code at each consumer call-site to
iterate over smaller page_vecs until that array is filled.
--
Chuck Lever
Reduce the rate at which nfsd threads hammer on the page allocator.
This improves throughput scalability by enabling the threads to run
more independently of each other.
Signed-off-by: Chuck Lever
---
Hi Mel-
This patch replaces patch 5/7 in v4 of your alloc_pages_bulk()
series. It implements
an
> wrote:
>>
>> From: Chuck Lever
>>
>> Reduce the rate at which nfsd threads hammer on the page allocator.
>> This improves throughput scalability by enabling the threads to run
>> more independently of each other.
>>
>> Signed-off-by: Chuck Lever
lease_secctx() can use the
> correct hook.
>
> Acked-by: Stephen Smalley
> Acked-by: Paul Moore
> Reviewed-by: John Johansen
> Signed-off-by: Casey Schaufler
> Cc: linux-...@vger.kernel.org
For the NFSD hunks in 15/25 and 17/25:
Acked-by: Chuck Lever
> On Mar 11, 2021, at 6:49 AM, Mel Gorman wrote:
>
> From: Chuck Lever
>
> Reduce the rate at which nfsd threads hammer on the page allocator.
> This improve throughput scalability by enabling the threads to run
> more independently of each other.
Mel, if you shou
dename);
> + if (clnt->cl_nodelen == -E2BIG) {
> + err = -ENOMEM;
> + goto out_no_path;
> + }
>
> err = rpc_client_register(clnt, args->authflavor, args->client_name);
> if (err)
>
--
Chuck Lever
ller.appspot.com/x/repro.c?x=12e9e0dad0
>
> The issue was bisected to:
>
> commit c8e88e3aa73889421461f878cd569ef84f231ceb
> Author: Chuck Lever
> Date: Tue Nov 3 20:06:04 2020 +
>
>NFSD: Replace READ* macros in nfsd4_decode_layoutget()
>
> bisect
> On Feb 26, 2021, at 10:19 AM, Joe Korty wrote:
>
> On Fri, Feb 26, 2021 at 03:15:46PM +0000, Chuck Lever wrote:
>>
>>
>>> On Feb 26, 2021, at 10:00 AM, J. Bruce Fields wrote:
>>>
>>> Adding Chuck, linux-nfs.
>>>
>>>
> [ 109.442600] ret_from_fork+0x22/0x30
>> [ 109.518225] nfsd: last server has exited, flushing export cache
>> [ OK ] Stopped NFSv4 ID-name mapping service.
>> [ OK ] Stopped GSSAPI Proxy Daemon.
>> [ OK ] Stopped NFS Mount Daemon.
>> [ OK ] Stopped NFS status monitor for NFSv2/3 locking..
>> Index: b/net/sunrpc/svc_xprt.c
>> ===
>> --- a/net/sunrpc/svc_xprt.c
>> +++ b/net/sunrpc/svc_xprt.c
>> @@ -1062,7 +1062,7 @@ static int svc_close_list(struct svc_ser
>> struct svc_xprt *xprt;
>> int ret = 0;
>>
>> -spin_lock(&serv->sv_lock);
>> +spin_lock_bh(&serv->sv_lock);
>> list_for_each_entry(xprt, xprt_list, xpt_list) {
>> if (xprt->xpt_net != net)
>> continue;
>> @@ -1070,7 +1070,7 @@ static int svc_close_list(struct svc_ser
>> set_bit(XPT_CLOSE, &xprt->xpt_flags);
>> svc_xprt_enqueue(xprt);
>> }
>> -spin_unlock(&serv->sv_lock);
>> +spin_unlock_bh(&serv->sv_lock);
>> return ret;
>> }
>>
>>
>
--
Chuck Lever
- add "select CRYPTO"
or
- add "depends on CRYPTO"
> --- a/fs/nfsd/Kconfig 2021-02-09 22:05:29.462030761 -0500
> +++ b/fs/nfsd/Kconfig 2021-02-11 12:00:48.974076992 -0500
> @@ -73,6 +73,7 @@
> select NFSD_V3
> select FS_POSIX_ACL
> select SUNRPC_GSS
> + select CRYPTO
> select CRYPTO_MD5
> select CRYPTO_SHA256
> select GRACE_PERIOD
>
>
--
Chuck Lever
gets delegated to
> the normal allocator. The same criteria should apply to any other users.
>
> include/linux/gfp.h | 13 +
> mm/page_alloc.c | 113 +-
> net/sunrpc/svc_xprt.c | 47 ++++--
> 3 files changed, 157 insertions(+), 16 deletions(-)
Hi Mel-
Thank you for carrying the torch!
--
Chuck Lever
0% reproducible with any kernel from 4.9 to 5.4, stable or backports. It
> may exist in earlier versions, but I do not have a machine with anything
> before 4.9 to test at present.
Confirming you are varying client-side kernels. Should the Linux
NFS client maintainers be Cc'd?
> From 1-2 make clean && make cycles to one afternoon depending on the number
> of machine cores. More cores/threads the faster it does it.
>
> I tried playing with protocol minor versions, caching options, etc - it is
> still reproducible for any nfs4 settings as long as there is client side
> caching of metadata.
>
> A.
>
>>
>> Regards,
>> Salvatore
>>
>
> --
> Anton R. Ivanov
> Cambridgegreys Limited. Registered in England. Company Number 10273661
> https://www.cambridgegreys.com/
--
Chuck Lever
> On Feb 8, 2021, at 3:12 PM, Trond Myklebust wrote:
>
> On Mon, 2021-02-08 at 19:48 +0000, Chuck Lever wrote:
>>
>>
>>> On Feb 8, 2021, at 2:34 PM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Tue, 2021-
> On Feb 8, 2021, at 2:34 PM, Trond Myklebust wrote:
>
> On Tue, 2021-01-19 at 20:25 -0500, Sasha Levin wrote:
>> From: Chuck Lever
>>
>> [ Upstream commit 4a85a6a3320b4a622315d2e0ea91a1d2b013bce4 ]
>>
>> Daire Byrne reports a ~50% aggregrate th
Hi Dan-
> On Jan 28, 2021, at 10:34 AM, Dan Carpenter wrote:
>
> On Thu, Jan 28, 2021 at 03:05:06PM +0000, Chuck Lever wrote:
>> Hi Colin-
>>
>>> On Jan 28, 2021, at 9:49 AM, Colin King wrote:
>>>
>>> From: Colin Ian King
>>>
>>
,
> stateid_t *st,
>
> *stid = find_stateid_by_type(found, &cps->cp_p_stateid,
> NFS4_DELEG_STID|NFS4_OPEN_STID|NFS4_LOCK_STID);
> - if (stid)
> + if (*stid)
> status = nfs_ok;
> else
> status = nfserr_bad_stateid;
> --
> 2.29.2
>
--
Chuck Lever
gt; +while ((page = readahead_page(rac))) {
>> +ret = readpage_async_filler(&desc, page);
>> +put_page(page);
>> +}
>
> I thought with the new API we didn't need to do this kind of thing
> any more? ie no matter whether fscache is configured in or not, it'll
> submit the I/Os.
--
Chuck Lever
that did that, and I don't remember the history. I thought it was
> required by some spec or peer implementation (maybe Windows?) but I
> really don't remember. It may predate git. I'll dig around and see
> what I can find.
I can't add more here, this design comes from well before I started
working on this body of code (though, I worked near Kevin when he
implemented it).
--
Chuck Lever
g/projects/cel/cel-2.6.git
Incidentally, the e-mail encoding mangled the white space and I
don't see the e-mail showing up on lore.kernel.org. I applied it
by hand since it was small, but this should be addressed for
future patches so our patch handling infrastructure can deal
properly with your submissions. Thanks!
--
Chuck Lever
struct inode *inode = d_inode(fhp->fh_dentry);
> - __be32 err;
> + __be32 err = 0;
>
> if (fhp->fh_post_saved)
> printk("nfsd: inode locked twice during operation.\n");
> --
> 1.9.1
>
--
Chuck Lever
it
> for the merge window.
Applied for the v5.11 merge window with Bruce's suggested change,
and pushed to the cel-next branch in
git://git.linux-nfs.org/projects/cel/cel-2.6.git
or
https://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary
>> goto out_notifier;
>> }
>>
>> --
>> 2.22.0
--
Chuck Lever
ot;nfsd4: don't query change attribute in v2/v3 case")
>
> are missing a Signed-off-by from their committers.
My bad. I assumed my SoB was not required because I didn't alter the
patch in any way.
But, now fixed in my public repo.
--
Chuck Lever
d/nfsctl.c
> @@ -1165,6 +1165,7 @@ static struct inode *nfsd_get_inode(struct super_block
> *sb, umode_t mode)
> inode->i_fop = &simple_dir_operations;
> inode->i_op = &simple_dir_inode_operations;
> inc_nlink(inode);
> + break;
> default:
> break;
> }
> --
> 2.27.0
>
Acked-by: Chuck Lever
--
Chuck Lever
> On Nov 12, 2020, at 4:07 PM, Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
>> Chuck Lever wrote:
>>
>>> Really? My understanding of the Linux kernel SUNRPC implementation is
>>> that it uses asynchronous, eve
pc/rxgk.c | 1232 ++
>> net/rxrpc/rxgk_app.c | 424 ++++++
>> net/rxrpc/rxgk_common.h | 164
>> net/rxrpc/rxgk_kdf.c | 271 +++
>> net/rxrpc/security.c |6 +
>> 26 files changed, 5530 insertions(+), 1 deletion(-)
>> create mode 100644 crypto/krb5/kdf.c
>> create mode 100644 crypto/krb5/rfc3961_simplified.c
>> create mode 100644 crypto/krb5/rfc3962_aes.c
>> create mode 100644 crypto/krb5/rfc6803_camellia.c
>> create mode 100644 crypto/krb5/rfc8009_aes2.c
>> create mode 100644 crypto/krb5/selftest.c
>> create mode 100644 crypto/krb5/selftest_data.c
>> create mode 100644 net/rxrpc/rxgk.c
>> create mode 100644 net/rxrpc/rxgk_app.c
>> create mode 100644 net/rxrpc/rxgk_common.h
>> create mode 100644 net/rxrpc/rxgk_kdf.c
--
Chuck Lever
> On Nov 12, 2020, at 10:42 AM, David Howells wrote:
>
> Chuck Lever wrote:
>
>>> There are three main interfaces to it:
>>>
>>> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>>>
>>>These all do in-place crypto, usi
d.c
> create mode 100644 crypto/krb5/rfc3962_aes.c
> create mode 100644 crypto/krb5/rfc6803_camellia.c
> create mode 100644 crypto/krb5/rfc8009_aes2.c
> create mode 100644 crypto/krb5/selftest.c
> create mode 100644 crypto/krb5/selftest_data.c
> create mode 100644 net/rxrpc/rxgk.c
> create mode 100644 net/rxrpc/rxgk_app.c
> create mode 100644 net/rxrpc/rxgk_common.h
> create mode 100644 net/rxrpc/rxgk_kdf.c
>
>
--
Chuck Lever
> On Nov 6, 2020, at 12:40 AM, Alex Shi wrote:
>
> The macro is unused, remove it to tame gcc warning:
> fs/nfsd/nfs3proc.c:702:0: warning: macro "nfsd3_fhandleres" is not used
> [-Wunused-macros]
>
> Signed-off-by: Alex Shi
> Cc: "J. Bruce Fi
return NF4SOCK;
> default:return NF4BAD;
> - };
> + }
> }
>
> static inline __be32
> --
> 2.18.1
>
I can take this for 5.11.
--
Chuck Lever
6efa8cbfb, the original
issue won't appear with Linux clients, because they use TCP to handle
the ACCEPT_SEC_CONTEXT handshake. You'd need to have both Solaris and
RDMA to test it. Maybe we can scrounge something up, but that would only
be enough to ensure that your patch doesn't regress the Solaris NFS/RDMA
with Kerberos setup when using small tokens.
--
Chuck Lever
> On Oct 15, 2020, at 9:59 AM, Trond Myklebust wrote:
>
> On Thu, 2020-10-15 at 09:36 -0400, Chuck Lever wrote:
>>> On Oct 15, 2020, at 8:06 AM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Thu, 2020-10-15 at 00:39 +0530,
> On Oct 15, 2020, at 9:59 AM, Trond Myklebust wrote:
>
> On Thu, 2020-10-15 at 09:36 -0400, Chuck Lever wrote:
>>> On Oct 15, 2020, at 8:06 AM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Thu, 2020-10-15 at 00:39 +0530,
; "
> Other attributes SHOULD NOT be made available for absent file
> systems, even when it is possible to provide them. The server should
> not assume that more information is always better and should avoid
> gratuitously providing additional information."
>
> So why is the client asking for them?
This paragraph (and it's most modern incarnation in RFC 8881 Section
11.4.1) describes server behavior. The current client behavior is
spec-compliant because there is no explicit prohibition in the spec
language against a client requesting additional attributes in this
case.
Either the server can clear those bitmap flags on the GETATTR reply
and not supply those attributes, and clients must be prepared for
that.
Or, it's also possible to read this paragraph to mean that the
server can provide those attributes and the values should not
reflect attributes for the absent file system, but rather something
else (eg, server-manufactured defaults, or the attributes from the
object on the source server).
And since this is a SHOULD NOT rather than a MUST NOT, servers are
still free to return information about the absent file system.
Clients are not guaranteed this will be the case, however.
I don't think c05cefcc7241 makes any assumption about whether the
server is lying about the extra attributes. Perhaps the server has
no better values for these attributes than the client's defaults
were.
--
Chuck Lever
13a9a9d74d4d9689ad65938966dbc66386063648:
SUNRPC: Fix svc_flush_dcache() (2020-09-21 10:13:25 -0400)
Fixes:
- Incorrect calculation on platforms that implement flush_dcache_page()
Chuck Lever (1
4859 left -= slen + 1;
> 4860 }
> 4861
> 4862 /*
> 4863 * If there were user attributes to copy, but we didn't copy
> 4864 * any, the offset was too large (e.g. the cookie was invalid).
> 4865 */
> 4866 if (nuser > 0 && count == 0) {
> 4867 status = nfserr_badcookie;
> 4868 goto out;
> 4869 }
> 4870
> 4871 wreof:
> 4872 p = xdr_reserve_space(xdr, 4);
> 4873 if (!p) {
> 4874 status = nfserr_resource;
> 4875 goto out;
> 4876 }
> 4877 *p = cpu_to_be32(eof);
> 4878
> 4879 cookie = offset + count;
> 4880
> 4881 write_bytes_to_xdr_buf(xdr->buf, cookie_offset, &cookie, 8);
>> 4882 count = htonl(count);
> 4883 write_bytes_to_xdr_buf(xdr->buf, count_offset, &count, 4);
> 4884 out:
> 4885 if (listxattrs->lsxa_len)
> 4886 kvfree(listxattrs->lsxa_buf);
> 4887 return status;
> 4888 }
> 4889
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> <.config.gz>
--
Chuck Lever
> On Sep 22, 2020, at 3:13 AM, He Zhe wrote:
>
>
>
> On 9/21/20 3:51 AM, Chuck Lever wrote:
>> On platforms that implement flush_dcache_page(), a large NFS WRITE
>> triggers the WARN_ONCE in bvec_iter_advance():
>>
>> Sep 20 14:01:05 klimt.1015grange
//
> @@
> expression x,n,flags;
> @@
>
> x =
> - kcalloc
> + kmalloc_array
> (n,sizeof(*x),flags)
> ...
> sg_init_table(x,n)
> //
>
> Signed-off-by: Julia Lawall
Acked-by: Chuck Lever
This one goes to Anna.
> ---
> net/sunrpc/xprtrdma/frwr_op
> 0)
> + if (len > (seek & PAGE_MASK))
I don't understand how this addresses the WARNING. Can you provide
an example set of inputs that trigger the issue?
Also this change introduces a mixed-sign comparison, so NACK on
this particular patch unless it can be demonstrated that the
implicit type conversion here is benign (I don't think it is,
but I haven't thought through it).
> svc_flush_bvec(bvec, len, seek);
>
> /* If we read a full record, then assume there may be more
> --
> 2.17.1
>
--
Chuck Lever
J. Bruce Fields (1):
nfsd: fix oops on mixed NFSv4/NFSv3 client access
Wang Hai (1):
SUNRPC: remove duplicate include
fs/nfsd/nfs4state.c | 2 ++
net/sunrpc/auth_gss/trace.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
--
Chuck Lever
ct svc_fh
> *fhp,
> *created = true;
> goto set_attr;
> }
> - /* fall through */
> + fallthrough;
> case NFS3_CREATE_GUARDED:
> err = nfserr_exist;
> }
> --
> 2.19.1
>
--
Chuck Lever
00644
> --- a/net/sunrpc/auth_gss/trace.c
> +++ b/net/sunrpc/auth_gss/trace.c
> @@ -9,7 +9,6 @@
> #include
> #include
> #include
> -#include
>
> #define CREATE_TRACE_POINTS
> #include
> --
> 2.17.1
>
--
Chuck Lever
*created = true;
> goto set_attr;
> }
> - /* fall through */
> + fallthrough;
> case NFS3_CREATE_GUARDED:
> err = nfserr_exist;
> }
> --
> 2.19.1
>
--
Chuck Lever
> On Aug 13, 2020, at 11:10 AM, James Bottomley
> wrote:
>
> On Thu, 2020-08-13 at 10:42 -0400, Chuck Lever wrote:
>>> On Aug 12, 2020, at 11:51 AM, James Bottomley >> enPartnership.com> wrote:
>>> On Wed, 2020-08-12 at 10:15 -0400, Chuck Lever wr
p = xdr_encode_opaque(p, sp, slen);
>> + xdr_encode_opaque(p, sp, slen);
>>
>>xdrleft -= xdrlen;
>>count++;
>> --
>> 2.28.0
>>
>
> Yep, I guess my linting missed that, thanks for the fix.
Bruce, these two don't appear to be urgent, so I'm deferring them
to you for v5.10.
--
Chuck Lever
> On Aug 13, 2020, at 10:42 AM, James Bottomley
> wrote:
>
> On Thu, 2020-08-13 at 10:21 -0400, Chuck Lever wrote:
>>> On Aug 12, 2020, at 11:42 AM, James Bottomley >> enPartnership.com> wrote:
> [...]
>>> For most people the security mechanism of
> On Aug 12, 2020, at 11:51 AM, James Bottomley
> wrote:
>
> On Wed, 2020-08-12 at 10:15 -0400, Chuck Lever wrote:
>>> On Aug 11, 2020, at 11:53 AM, James Bottomley
>>> wrote:
>>>
>>> On Tue, 2020-08-11 at 10:48 -0400, Chuck Lever wrote:
> On Aug 12, 2020, at 11:42 AM, James Bottomley
> wrote:
>
> On Wed, 2020-08-12 at 09:56 -0400, Chuck Lever wrote:
>>> On Aug 11, 2020, at 2:28 PM, James Bottomley >> nPartnership.com> wrote:
>>>
>>> On Tue, 2020-08-11 at 10:48 -0400, Chuck Le
> On Aug 11, 2020, at 11:32 AM, James Bottomley
> wrote:
>
> On Tue, 2020-08-11 at 10:48 -0400, Chuck Lever wrote:
>>> On Aug 11, 2020, at 1:43 AM, James Bottomley
>>> wrote:
>>> On Mon, 2020-08-10 at 19:36 -0400, Chuck Lever wrote:
> [...]
>>
> On Aug 11, 2020, at 5:03 PM, James Morris wrote:
>
> On Sat, 8 Aug 2020, Chuck Lever wrote:
>
>> My interest is in code integrity enforcement for executables stored
>> in NFS files.
>>
>> My struggle with IPE is that due to its dependence on dm-ve
> On Aug 11, 2020, at 11:53 AM, James Bottomley
> wrote:
>
> On Tue, 2020-08-11 at 10:48 -0400, Chuck Lever wrote:
>>> On Aug 11, 2020, at 1:43 AM, James Bottomley >> nPartnership.com> wrote:
>>>
>>> On Mon, 2020-08-10 at 19:36 -0400, Chuck
> On Aug 11, 2020, at 2:28 PM, James Bottomley
> wrote:
>
> On Tue, 2020-08-11 at 10:48 -0400, Chuck Lever wrote:
>> Mimi's earlier point is that any IMA metadata format that involves
>> unsigned digests is exposed to an alteration attack at rest or in
>&g
> On Aug 11, 2020, at 1:43 AM, James Bottomley
> wrote:
>
> On Mon, 2020-08-10 at 19:36 -0400, Chuck Lever wrote:
>>> On Aug 10, 2020, at 11:35 AM, James Bottomley
>>> wrote:
>>> On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote:
>>>> O
> On Aug 11, 2020, at 2:15 AM, Stephen Rothwell wrote:
>
> Hi Chuck,
>
> On Mon, 10 Aug 2020 08:25:14 -0400 Chuck Lever wrote:
>>
>> Is there something I need to change? The public copy of the cel-testing
>> branch has had this content for the past 12 days
> On Aug 10, 2020, at 11:35 AM, James Bottomley
> wrote:
>
> On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote:
>> On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote:
>>>> On Aug 5, 2020, at 2:15 PM, Mimi Zohar
>>>> wrote:
>>
>>
> On Aug 9, 2020, at 7:03 PM, Stephen Rothwell wrote:
>
> Hi Chuck,
>
> On Sun, 9 Aug 2020 11:44:15 -0400 Chuck Lever wrote:
>>
>> The following changes since commit 11ba468877bb23f28956a35e896356252d63c983:
>>
>> Linux 5.8-rc5 (2020-07-12 16:34:50
--
32 files changed, 1807 insertions(+), 466 deletions(-)
create mode 100644 include/linux/sunrpc/rpc_rdma_cid.h
--
Chuck Lever
> On Aug 5, 2020, at 2:15 PM, Mimi Zohar wrote:
>
> On Wed, 2020-08-05 at 09:59 -0700, James Morris wrote:
>> On Wed, 5 Aug 2020, James Bottomley wrote:
>>
>>> I'll leave Mimi to answer, but really this is exactly the question that
>>> should have been asked before writing IPE. However, sinc
@@ static void set_max_drc(void)
> nfsd_drc_max_mem = (nr_free_buffer_pages()
> >> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE;
> nfsd_drc_mem_used = 0;
> - spin_lock_init(&nfsd_drc_lock);
> dprintk("%s nfsd_drc_max_mem %lu \n", __func__, nfsd_drc_max_mem);
> }
>
> --
> 2.25.1
>
--
Chuck Lever
> On Jul 18, 2020, at 11:55 AM, Chuck Lever wrote:
>
>
>
>> On Jul 17, 2020, at 3:46 PM, Pierre Sauter wrote:
>>
>> Am Freitag, 17. Juli 2020, 19:56:09 CEST schrieb Kai-Heng Feng:
>>>> Pierre, thanks for confirming!
>>>>
>>>
> On Jul 19, 2020, at 8:14 PM, Randy Dunlap wrote:
>
> Drop the repeated word "the" in a comment.
>
> Signed-off-by: Randy Dunlap
> Cc: "J. Bruce Fields"
> Cc: Chuck Lever
> Cc: linux-...@vger.kernel.org
Acked-by: Chuck Lever
> ---
00 800f000f 0001
>
> [ 21.666152] page dumped because: kasan: bad access detected
>
> [ 21.666197] Memory state around the buggy address:
> [ 21.666228] 8883b6b7d380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> [ 21.666272] 8883b6b7d400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> [ 21.666315] >8883b6b7d480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc
> [ 21.666358]^
> [ 21.666379] 8883b6b7d500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc
> [ 21.666423] 8883b6b7d580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc
> [ 21.666465]
> ==
> [ 21.666509] Disabling lock debugging due to kernel taint
>
>
>
--
Chuck Lever
> On Jul 17, 2020, at 1:29 PM, Pierre Sauter wrote:
>
> Hi Chuck,
>
> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
>> So this makes me think there's a possibility you are not using upstream
>> stable kernels. I can't help if I d
Hi Pierre-
> On Jul 16, 2020, at 2:40 PM, Pierre Sauter wrote:
>
> Hi,
>
> Am 2020-07-15 20:54, schrieb Chuck Lever:
>> v5.4.40 does not have 31c9590ae468 and friends, but the claim is this
>> one crashes?
>
> To my knowledge 31c9590ae468 and friends are in
> On Jul 15, 2020, at 11:14 AM, Chuck Lever wrote:
>
>
>
>> On Jul 15, 2020, at 11:08 AM, Kai-Heng Feng
>> wrote:
>>
>>> On Jul 15, 2020, at 23:02, Chuck Lever wrote:
>>>
>>>> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
&
> On Jul 15, 2020, at 12:31 PM, Colin Ian King wrote:
>
> Bah, $SUBJECT typo "calcations" -> "calculations". can that be fixed up
> when it's applied, or shall I send a V2?
Anna's preference.
Reviewed-by: Chuck Lever
> On 15/07/2020
header_size.
>
> The commit in question is relatively old:
>
> commit 302d3deb20682a076e1ab551821cacfdc81c5e4f
> Author: Chuck Lever
> Date: Mon May 2 14:41:05 2016 -0400
>
>xprtrdma: Prevent inline overflow
>
> The two issues are as follows:
>
> Issue #1:
> On Jul 15, 2020, at 11:08 AM, Kai-Heng Feng
> wrote:
>
>> On Jul 15, 2020, at 23:02, Chuck Lever wrote:
>>
>>> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
>>> wrote:
>>>
>>> Hi,
>>>
>>> Multiple users rep
"SUNRPC: Revert 241b1f419f0e ("SUNRPC: Remove
xdr_buf_trim()")")
is also applied to 5.4.0-40-generic.
It would help to know if v5.5 stable is working for you. I haven't had any
problems with it.
--
Chuck Lever
turn 0;
> }
>
> @@ -346,7 +346,7 @@ nametoid_show(struct seq_file *m, struct cache_detail
> *cd, struct cache_head *h)
> ent->name);
> if (test_bit(CACHE_VALID, &h->flags))
> seq_printf(m, " %u", ent->id);
> - seq_printf(m, "\n");
> + seq_putc(m, '\n');
> return 0;
> }
>
> --
> 2.17.1
>
--
Chuck Lever
> net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE" is
> not defined [-Wundef]
> #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
> ^
>
> Include linux/highmem.h so that asm/cacheflush.h will be included.
>
> Reported-by: Christophe Lero
svcsock.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 5c4ec9386f81..d9e99cb09aab 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -45,6 +45,7 @@
> #include
> #include
> #include
> +#include
Nit: Let's include in net/sunrpc/svcsock.h instead
of directly.
> #include
> #include
> --
> 2.25.0
>
--
Chuck Lever
5 for_each_bvec(bv, bvec, bi, bi)
> 236 flush_dcache_page(bv.bv_page);
> 237 }
> 238 #else
> 239 static inline void svc_flush_bvec(const struct bio_vec *bvec, size_t
> size,
> 240 size_t seek)
> 241 {
> 242 }
> 243 #endif
> 244
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> <.config.gz>
--
Chuck Lever
mbolic(family,\
> + { AF_UNSPEC,"AF_UNSPEC" }, \
> + { AF_UNIX, "AF_UNIX" },\
> + { AF_LOCAL, "AF_LOCAL" }, \
> + { AF_INET, "AF_INET" },\
> + { AF_INET6, "AF_INET6" })
> +
> -DECLARE_EVENT_CLASS(xdr_buf_class,
> +DECLARE_EVENT_CLASS(rpc_xdr_buf_class,
> TP_PROTO(
> + const struct rpc_task *task,
> const struct xdr_buf *xdr
> ),
>
--
Chuck Lever
1 - 100 of 251 matches
Mail list logo
