On Tue, 2008-04-08 at 14:22 -0400, Talpey, Thomas wrote: > At 02:00 PM 4/8/2008, Trond Myklebust wrote: > >As I said, it looks to me as if a report other than ENOTCONN or > >ETIMEDOUT will automatically result in the rpc task aborting. > > FWIW, we've seen some leaks on NFS/RDMA clients that receive strange > errors from the RDMA layer when connecting to the server. I hope to be > able to test this soon to see if it eliminates the leak, but don't have the > ability to do that where I am right now. > > Anyway, the RDMA layer does return some very different errors from > sockets. We attempt to "fix" them in the RPC transport before returning > them, but it's a bit of a challenge so I would welcome error hardening in > the layer(s) above. The only justification for passing more errors up to the higher layers is if they have different error handling requirements. The reason why we currently transform more or less everything into ENOTCONN is because the two other errors ECONNRESET and ECONNREFUSED basically require the same kind of error handling (exit with EIO in the "soft" case, and keep retrying in the "hard" case). So, what kind of RDMA errors are these, and how are we failing to handle them correctly today? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
