From: Chuck Lever <chuck.lever@oracle.com>
Date: Thu, 14 Dec 2017 20:56:01 -0500
Subject: xprtrdma: Fix buffer leak after transport set up failure
Patch-mainline: v4.16-rc1
Git-commit: 03ac1a76ce5e5a6052a421e1d6a5c97778e88a8c
References: bsc#1103992 FATE#326009
This leak has been around forever, and is exceptionally rare.
EINVAL causes mount to fail with "an incorrect mount option was
specified" although it's not likely that one of the mount
options is incorrect. Instead, return ENODEV in this case, as this
appears to be an issue with system or device configuration rather
than a specific mount option.
Some obsolete comments are also removed.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Acked-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
---
net/sunrpc/xprtrdma/transport.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -414,20 +414,10 @@ xprt_setup_rdma(struct xprt_create *args
if (rc)
goto out2;
- /*
- * Allocate pre-registered send and receive buffers for headers and
- * any inline data. Also specify any padding which will be provided
- * from a preregistered zero buffer.
- */
rc = rpcrdma_buffer_create(new_xprt);
if (rc)
goto out3;
- /*
- * Register a callback for connection events. This is necessary because
- * connection loss notification is async. We also catch connection loss
- * when reaping receives.
- */
INIT_DELAYED_WORK(&new_xprt->rx_connect_worker,
xprt_rdma_connect_worker);
@@ -448,8 +438,9 @@ xprt_setup_rdma(struct xprt_create *args
return xprt;
out4:
+ rpcrdma_buffer_destroy(&new_xprt->rx_buf);
xprt_rdma_free_addresses(xprt);
- rc = -EINVAL;
+ rc = -ENODEV;
out3:
rpcrdma_ep_destroy(new_ep, &new_xprt->rx_ia);
out2: