On Wed, Jul 31, 2024 at 08:44:55PM +0800, Yunsheng Lin wrote:
> Use appropriate frag_page API instead of caller accessing
> 'page_frag_cache' directly.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsheng Lin
> Reviewed-by: Alexander Duyck
For the net/sunrpc/svcs
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 +, 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
age
> cache readahead, fault around and SLUB allocations when high-order pages
> are unavailable. It's unknown how much benefit would be seen by converting
> multiple page allocation calls to a single batch or what difference it may
> make to headline performance. It's a chicke
> 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 +, Chuck Lever III wrote:
>>> IME lists are indeed less CPU-efficient, but I wonder if that
>>> exp
> On Mar 13, 2021, at 11:39 AM, Matthew Wilcox wrote:
>
> On Sat, Mar 13, 2021 at 01:16:48PM +, Mel Gorman wrote:
>>> I'm not claiming the pagevec is definitely a win, but it's very
>>> unclear which tradeoff is actually going to lead to better perfo
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.
>>>
>>>
> On Feb 26, 2021, at 10:00 AM, J. Bruce Fields wrote:
>
> Adding Chuck, linux-nfs.
>
> Makes sense to me.--b.
Joe, I can add this to nfsd-5.12-rc. Would it be appropriate to add:
Fixes: 719f8bcc883e ("svcrpc: fix xpt_list traversal locking on shutdown")
> O
- 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
-- the first which adds the required semantic to
> the bulk allocator and the second which adds the new user.
>
> Patch 1 of this series is a cleanup to sunrpc, it could be merged
> separately but is included here for convenience.
>
> Patch 2 is the prototype bulk allocato
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
> On Dec 4, 2020, at 10:46 AM, Bruce Fields wrote:
>
> On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
>> Hi Chuck, Bruce,
>>
>> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
>> gss_krb5_aes_encrypt() code looks like
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
ech *ctx = crypto_mech_alloc("krb5(18)");
>>
>> to get enctype 18, but I'm not sure if it's worth the effort. Also, I'm
>> not sure if there are any alternatives to kerberos we will need to support.
>
> We did have code for a non-krb5 mechanism at some
> 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
This leaves the last bytes of page 0
>>> unwritten.
>>>
>>> Next to that, the remaining data is in page 0 of rqstp->rq_arg.pages,
>>> not page 1.
>>
>> Got it, thanks. Looks like the culprit might be a patch from a year ago
>> from Chuck, 5
> 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,
node, hence the
>>> existing code.
>>
>> Hi Trond, thanks for reviewing the patch!
>> Sorry but I didn't understand the reason to NACK it. Could you please
>> elaborate your concern?
>> These are the current attributes we request from the server on a
>>
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
recent krb5p regression
- Address a few resource leaks and a rare NULL dereference
Other:
- De-duplicate RPC/RDMA error handling and other utility functions
- Replace storage and display of kernel memory addresses by tracepoints
Chuck
> 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
> ---
, good to know that it's fixed in upstream stable, everything's good
>> now!
>> Thanks for your effort Chuck.
>>
>> Kai-Heng
>
> Sorry to have caused premature happiness. Kai-Hengs last message reminded me
> that I had seen the bug earlier in the week on
> 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
sunrpc/svcsock.o
> net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE" is
> not defined [-Wundef]
> #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
> ^
>
> Fixes: ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()")
> Signed-off-by: Christophe Ler
Hello-
> On Jun 12, 2020, at 2:31 AM, kernel test robot wrote:
>
> Hi Chuck,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: b791d1bdf9212d944d749a
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 1025 matches
Mail list logo
