xprtrdma: Fix buffer leak after transport set up failure

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>

1 files changed, 2 insertions, 11 deletions

diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 6ee1ad8978f3..7f9b62822807 100644
--- 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: