On Thu, 2010-10-21 at 10:31 -0400, Chuck Lever wrote: > On Oct 21, 2010, at 10:05 AM, Trond Myklebust wrote: > > It seems to me that the problem is basically that RPC_IS_SOFTCONN is > > poorly defined. IMO, the definition should really be that > > 'RPC_IS_SOFTCONN' tasks MUST exit with an error if they ever have to run > > call_bind or a call_connect more than once (i.e. if they ever have to > > loop back). > > I think you are suggesting that we define the places where RPC_IS_SOFTCONN should be tested as exactly those places that might want to restart the RPC call via rpc_force_rebind, tk_action = call_refresh, and so on. Yes? Yes. > > With that in mind, I really don't see why the RPC_IS_SOFTCONN case is > > being handled in call_transmit_status() instead of in call_status(). > > I tried it in call_status(), but it didn't work as expected. My notes aren't specific about the problem. One thing is for sure, there seems to be some redundant error handling logic in both of those states. Unraveling it might be more than Neil bargained for, but would help "future generations." call_transmit_status() is there basically in order to call xprt_end_transmit() in the cases where we want to free up the socket write lock (and then possibly sleep). Actual state error handling is supposed occur in call_status(). Cheers Trond -- 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
