On Mon, 2020-04-20 at 10:59 -0400, Olga Kornievskaia wrote: > > > On Mon, Apr 20, 2020 at 10:53 AM Olga Kornievskaia < > olga.kornievskaia@xxxxxxxxx> wrote: > > > > Yes we are consistent in requesting to same connection to with the > > same channel binding, but we don't send BIND_CONN_TO_SESSION as the > > first thing on the "main" connection (ie connection that cared the > > CREATE_SESSION and was bound to fore and back channel by default). > > When that connection is reset, the first thing that happens is the > > client re-sends the operation that was not replied to. That has a > > SEQUENCE and by the rule the server binds that connection to the > > fore channel only (and sets the callback being down). We then send > > BIND_CONN_TO_SESSION and request FORE_OR_BOTH where this has > > already been bound to FORE only. > > > > > How about this: before we send BIND_CONN_TO_SESSION with > fore_or_both, we somehow always reset the connection (maybe you were > suggestion that already and i wasn't following). No. I didn't realise that we were being automatically set to just the fore channel. However as I said earlier, the spec says that the server MUST reply with NFS4ERR_INVAL in this case. It is not allowed to just return NFS4_OK and silently set the wrong channel binding. On the client we should probably do something to track whether or not the backchannel has been lost due to connection breakage. We probably need to allow the client to check the xprt->connect_cookie to find out if the connection broke. > i don't think this is going to the list as i'm getting auto > rejections emails but i don't know how to fix it. You need to turn off HTML mail. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
