On Mon, Apr 20, 2020 at 3:02 PM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > 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. How's this: client sends BIND_CONN_TO_SESSION with FORE_OR_BOTH, server select FORE channel. connection breaks before the reply gets to the client. Client resends. Is the server suppose to now fail with ERR_INVAL? There actually is such a thing between demand and request. FORE and BACK are demands and FORE_OR_BOTH and BACK_OR_BOTH are requests. The spec writes only about demands and not the requests. I believe that's intentional because BIND_CONN_TO_SESSIOn doesn't have a sequence and not protected by reply session semantics. > 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. hm.. google tells me it's plain text mode for the message... so i'm not sure. > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
