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
(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
+++--
> include/linux/fs_struct.h | 4 +
> include/linux/sunrpc/svc.h | 93 ++---
> include/linux/sunrpc/svc_xprt.h | 3 +
> include/linux/sunrpc/svcsock.h | 1 +
> include/trace/events/sunrpc.h | 88 ++--
> net/sunrpc/Makefile | 2
isable functions will likely oops when fed an RDMA
>>> xprt. Turn these functions into rpc_xprt_ops so that that doesn't
>>> occur. For now the RDMA versions are no-ops.
>>>
>>> Cc: Chuck Lever
>>> Signed-off-by: Jeff Layton
>>> ---
&
MA versions are no-ops that just return -EINVAL
> on an attempt to swapon.
>
> Cc: Chuck Lever
> Signed-off-by: Jeff Layton
Thanks, Jeff, that works for me.
Reviewed-by: Chuck Lever
> ---
> include/linux/sunrpc/xprt.h | 16 ++--
> net/sunrpc/clnt.c
wapper refcount goes to 0, untag the socket as a memalloc socket.
> + */
> +void
> +xs_swapper_disable(struct rpc_xprt *xprt)
> +{
> + struct sock_xprt *transport = container_of(xprt, struct sock_xprt,
> + xprt);
> +
> + if (atomic_dec_and_test(&xpr
please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug report.
> Note: all commands must start from beginning of the line in the email body.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
- 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
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
>>>
>>
> 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
> 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-
> [ 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
> 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 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 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 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: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 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 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: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:
> [...]
>>
@@ 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
ct svc_fh
> *fhp,
> *created = true;
> goto set_attr;
> }
> - /* fall through */
> + fallthrough;
> case NFS3_CREATE_GUARDED:
> err = nfserr_exist;
> }
> --
> 2.19.1
>
--
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
--
32 files changed, 1807 insertions(+), 466 deletions(-)
create mode 100644 include/linux/sunrpc/rpc_rdma_cid.h
--
Chuck Lever
> 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
*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
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
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
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/
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
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
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
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
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
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
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
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
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
,
> 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
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
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
gt;> Hannes> proper (userland) API for it has been a long time missing.
>>
>> Before we throw the baby out with the bath water, maybe Darrick can fill
>> us in on the progress of the aio passthrough interface?
>
> I haven't made much progress on it -- I have
g a queue of NFS/RDMA work on bugzilla.kernel.org. Let’s create a
defect report there to document this, and it will get prioritized with the
rest. Paul, can you do that to start us off? Product “File system”, Component
“NFS”.
I can’t say that a warning on 32-bit x86 is going to be an e
ferred) in
register_shrinker(), but this array is not freed when the shrinker
is released.
Signed-off-by: Chuck Lever
---
mm/vmscan.c |1 +
1 file changed, 1 insertion(+)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 53f2f82..eea668d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -211,6 +211
On Sep 10, 2014, at 3:42 AM, Or Gerlitz wrote:
>
> On 9/9/2014 10:30 PM, Chuck Lever wrote:
>> This crash happens when booting v3.17-rcN on any of my IB-enabled
>> systems. I have both ConnectX-2 and mthca systems, all are affected.
>>
>> I b
On Sep 29, 2014, at 3:00 PM, Eric Dumazet wrote:
> On Mon, 2014-09-29 at 14:52 -0400, Chuck Lever wrote:
>
>> Is there a bugzilla report filed for this issue? Has there been any progress
>> towards a fix?
>
> This is fixed in Linus tree.
>
> http://git.kernel.o
" failed %i\n",
> + __func__, rc);
> + break;
> + case RPCRDMA_MEMWINDOWS_ASYNC:
> + case RPCRDMA_MEMWINDOWS:
> + rc = ib_dealloc_mw(r->r.mw);
> +
we noticed
> that FMR's had been leaked due to the coding error described above.
>
> Issue(1) was seen during a code review while debugging issue(2).
>
> Signed-off-by: Allen Andrews
Reviewed-by: Chuck Lever
> ---
>
> net/sunrpc/xprtrdma/verbs.c | 73 ++
with a timestamp that
cannot be represented via a u32, should it also return NFS3ERR_INVAL?
RFC 1813 does not provide guidance on the behavior nor does it suggest
a particular error status code. The Solaris 11 server appears to return
NFS3ERR_INVAL in this case.
An alternative would be to “cap” th
On Jun 2, 2014, at 2:58 PM, Roger Willcocks wrote:
>
> On Mon, 2014-06-02 at 11:04 -0400, Chuck Lever wrote:
>
>> NFSv2/3 timestamps are a pair of unsigned 32-bit values: one value for
>> seconds since midnight GMT Jan 1, 1970, and one value for nanoseconds.
>> (See
d(iter->dev, dev,
>> 5170
>> &iter->dev->adj_list.lower);
>> 5171}
>>
>> And the address __dev_queue_xmit+0x49 is translated by gdb into:
>>
>> (gdb) list *(__dev_queue_xmit+0x49)
>>
; This patch can be tested directly by:
>
> keyctl request2 user debug:fred a @s
> keyctl timeout %user:debug:fred 3
> sleep 4
> keyctl request2 user debug:fred a @s
>
> Without the patch, the last command gives error EKEYEXPIRED, but with the
> command it
ive workloads.
Often these APIs are invoked while one or more spinlocks are
held. That makes it easy to back up a lot of work if one of
these calls is slow for any reason.
For wake_up_bit(), this doesn’t include how long it takes before
the awoken process is run. With CPU-intensive workloads, it’s
of
On May 20, 2015, at 7:22 PM, Russell King - ARM Linux
wrote:
> On Fri, May 15, 2015 at 03:50:14PM +0100, Russell King - ARM Linux wrote:
>> On Fri, May 15, 2015 at 10:26:48AM -0400, Chuck Lever wrote:
>>> On May 15, 2015, at 10:24 AM, Russell King - ARM Linux
>>>
__linux__ */
> # if HAVE_UTIMENSAT
> if (fd < 0)
>{
> result = utimensat (AT_FDCWD, file, ts, 0);
> # ifdef __linux__
> /* Work around a kernel bug:
> http://bugzilla.redhat.com/442352
> http://bugzilla.redhat.com/44
*therefore trigger warnings.
> + * Defer the xmit to rds_send_worker() instead.
> + */
> + queue_delayed_work(rds_wq, &conn->c_send_w, 0);
> }
> }
>
> --
> 1.7.1
&g
, but bcodding says that it seems to point to
> some issue in sunrpc.
>
> And because I can easily reproduce this and I was able to do a bisect:
>
> 2c94b8eca1a26cd46010d6e73a23da5f2e93a19d is the first bad commit
> commit 2c94b8eca1a26cd46010d6e73a23da5f2e93a19d
> Auth
> On Sep 8, 2019, at 11:19 AM, Trond Myklebust wrote:
>
> On Sun, 2019-09-08 at 07:39 -0400, Benjamin Coddington wrote:
>> On 6 Sep 2019, at 16:50, Chuck Lever wrote:
>>
>>>> On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III <
>>>> ti...@math
> On Sep 8, 2019, at 12:47 PM, Trond Myklebust wrote:
>
> On Sun, 2019-09-08 at 11:48 -0400, Chuck Lever wrote:
>>> On Sep 8, 2019, at 11:19 AM, Trond Myklebust <
>>> tron...@hammerspace.com> wrote:
>>>
>>> On Sun, 2019-09-08 at 07:39 -0400
On Sep 3, 2019, at 3:06 PM, Jason L Tibbitts III wrote:
>> "WW" == Wolfgang Walter writes:
>
> WW> What filesystem do you use on the server? xfs?
>
> Yeah, it's XFS.
>
> WW> If yes, does it use 64bit inodes (or started to use them)?
>
> These filesystems aren't super old, and were all
> On Sep 11, 2019, at 12:25 PM, Benjamin Coddington wrote:
>
> On 6 Sep 2019, at 16:50, Chuck Lever wrote:
>
>>> On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III wrote:
>>>
>>>>>>>> "JBF" == J Bruce Fields writes:
>>>
> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington wrote:
>
>
> On 11 Sep 2019, at 12:39, Chuck Lever wrote:
>
>>> On Sep 11, 2019, at 12:25 PM, Benjamin Coddington
>>> wrote:
>>>
>
>>> Instead, I think we want to make sure the mic f
> On Sep 11, 2019, at 1:40 PM, Benjamin Coddington wrote:
>
> On 11 Sep 2019, at 13:29, Chuck Lever wrote:
>
>>> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
>>> wrote:
>>>
>>>
>>> On 11 Sep 2019, at 12:39, Chuck Lever
> On Sep 11, 2019, at 1:50 PM, Benjamin Coddington wrote:
>
> On 11 Sep 2019, at 13:40, Benjamin Coddington wrote:
>
>> On 11 Sep 2019, at 13:29, Chuck Lever wrote:
>>
>>>> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington
>>>> wrote:
>&g
> On Sep 11, 2019, at 12:16 PM, Scott Mayhew wrote:
>
> From: David Howells
>
> Split various bits relating to mount parameterisation out from
> fs/nfs/super.c into their own file to form the basis of filesystem context
> handling for NFS.
>
> No other changes are made to the code beyond re
%d, num_comp_vectors:%d\n",
> + slave, port, cq_attr.comp_vector, ibdev->num_comp_vectors);
> ctx->cq = ib_create_cq(ctx->ib_dev, mlx4_ib_tunnel_comp_handler,
> NULL, ctx, &cq_attr);
> if (IS_ERR(ctx->cq)) {
> --
> 2.20.1
>
--
Chuck Lever
> On Feb 19, 2019, at 12:32 PM, Håkon Bugge wrote:
>
>
>
>> On 19 Feb 2019, at 15:58, Chuck Lever wrote:
>>
>> Hey Håkon-
>>
>>> On Feb 18, 2019, at 1:33 PM, Håkon Bugge wrote:
>>>
>>> MAD packet sending/receiving is
ation. If
the client doesn't respond, the server revokes the delegation
unilaterally and other users are allowed to proceed.
--
Chuck Lever
l
I shortened the commit title so that the Fixes: line is shorter than 68
characters. I can leave these titles alone if that's preferred.
--
Chuck Lever
; instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Chuck Lever
> ---
> net/sunrpc/xprtrdma/svc_rdma_rw.c | 3 +--
> 1 file changed, 1 insertion(+
On Jan 15, 2019, at 6:38 PM, Paul Gortmaker
wrote:
> [Re: linux-next: Fixes tag needs some work in the nfs-anna tree] On
> 15/01/2019 (Tue 23:12) Takashi Iwai wrote:
>
>> On Tue, 15 Jan 2019 22:41:21 +0100,
>> Chuck Lever wrote:
>>>
>>> Hi Stephe
ote:
>> Hi all,
>>
>> Friendly ping:
>>
>> Who can take this?
>>
>> Thanks
>> --
>> Gustavo
>>
>> On 1/31/19 8:11 AM, Chuck Lever wrote:
>>>
>>>
>>>> On Jan 30, 2019, at 7:46 PM, Gustavo A. R. Silva
&g
> On Jul 23, 2019, at 9:51 PM, Navid Emamdoost
> wrote:
>
> xdr_inline_decode may return NULL, so the check is necessary. The base
> pointer will be dereferenced later in rpcrdma_inline_fixup.
NACK. When xdr_inline_decode is passed a zero “length” argument, it can never
return NULL.
> Sig
me to send a patch?
> Introduced by commit
>
> d1ab72afe681 ("svcrdma: Trace key RDMA API events")
--
Chuck Lever
> On May 10, 2018, at 11:24 AM, Bruce Fields wrote:
>
> On Thu, May 10, 2018 at 10:21:05AM -0400, Chuck Lever wrote:
>>
>>
>>> On May 9, 2018, at 8:42 PM, Stephen Rothwell wrote:
>>>
>>> Hi all,
>>>
>>> After merging th
he transport write lock. This logic was copied from
xdr_partial_copy_from_skb, which uses GFP_ATOMIC.
Recall that this is here because of GETACL. As I've stated in
the past, the correct solution is to ensure that these pages
are provided in every case by the upper layer, making this
alloc_page call site unnecessary.
--
Chuck Lever
chuckle...@gmail.com
t the svc_rdma* hunks go in a separate patch
to bfie...@redhat.com, cc: linux-rdma and linux-nfs.
Reviewed-by: Chuck Lever
> ---
> net/sunrpc/xprtrdma/fmr_ops.c | 12 ++--
> net/sunrpc/xprtrdma/frwr_ops.c | 12 ++--
> net/sunrpc/
e when they want to
> redrive the entire syscall from that level. That won't work for non-
> idempotent requests though. We'd need to do something more elaborate
> there.
There is a similar problem with NFS/RDMA.
An IB device driver can be unloaded at any time. The driver performs
an upcall to all consumers to request that they release all RDMA
resources associated with the device.
For RPC-over-RDMA, we could kill all running RPCs at this point. Or,
the RPCs could be suspended in place. The latter is desirable if the
device were re-inserted, or there were an alternate path to the NFS
server: then there would be no workload interruption.
Signals would have to be allowed so that ^C and soft timeouts still
work as expected.
--
Chuck Lever
Kind regards,
>> Valentin
>
> Hi,
>
> this is just a kind reminder that the issue above is now present in v4.2-rc1.
I somehow missed your previous note. You can start by reverting
commit 731d5cca8272.
--
Chuck Lever
--
To unsubscribe from this list: send the line "un
t into
>>>> both trees.
>>>
>>> So, on further inspection, it appears that there is a series of commits
>>> in the rdma tree that does basically the same as that nfsd tree commit
>>> above. So I have dropped the rdma tree again today. Please hav
> On Jan 6, 2016, at 7:01 AM, Chuck Lever wrote:
>
>
>> On Jan 4, 2016, at 2:36 PM, J. Bruce Fields wrote:
>>
>> On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote:
>>> On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
>>>> Hi al
> On Jan 6, 2016, at 7:15 AM, Christoph Hellwig wrote:
>
> On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
>> Part of the plan was that Doug's tree would be merged before
>> Bruce's. But the above problem description looks like the
>> maintainer
> On Jan 6, 2016, at 9:46 AM, Or Gerlitz wrote:
>
> On 1/6/2016 4:24 PM, Chuck Lever wrote:
>> Actually, one of Or's for-4.5 devattr patches doesn't appear to have the
>> proper Ack's for the changes under net/sunrpc/xprtrdma either.
>
> Chuck,
&g
> On Jan 6, 2016, at 10:52 AM, Or Gerlitz wrote:
>
> On 1/6/2016 5:20 PM, Chuck Lever wrote:
>>> Chuck,
>>> >
>>> >Lets be concrete... anything wrong with patch [1]?
>> Yes. It is missing Acked-by: lines from the maintainers of
>> those fi
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
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
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
> 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
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
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
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
> 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 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 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
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 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
; "
> 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
101 - 200 of 251 matches
Mail list logo
