[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180508161529.GD6151@fieldses.org>
Date: Tue, 8 May 2018 12:15:29 -0400
From: "bfields@...ldses.org" <bfields@...ldses.org>
To: Trond Myklebust <trondmy@...mer.space>
Cc: "syzbot+4b98281f2401ab849f4b@...kaller.appspotmail.com"
<syzbot+4b98281f2401ab849f4b@...kaller.appspotmail.com>,
"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
"anna.schumaker@...app.com" <anna.schumaker@...app.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"jlayton@...nel.org" <jlayton@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Chuck Lever <chucklever@...il.com>
Subject: Re: general protection fault in encode_rpcb_string
On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
> Yes, and we can probably convert it, and the other GFP_ATOMIC
> allocations in the rpcbind client to use GFP_NOFS in order to improve
> reliability.
Chuck, I think the GFP_ATOMIC is unnecessary here as well?
--b.
diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
index e8adad33d0bb..de90c6c90cde 100644
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@ -228,7 +228,7 @@ rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
/* XXX: Certain upper layer operations do
* not provide receive buffer pages.
*/
- *ppages = alloc_page(GFP_ATOMIC);
+ *ppages = alloc_page(GFP_NOFS);
if (!*ppages)
return -EAGAIN;
}
Powered by blists - more mailing lists