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>

diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 6ee1ad8978f3b2977de2798d1a76ded1af6f78c4..7f9b628228071e735ce9fba03d3fe4ce59655578 100644 (file)
--- 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: