On Tue, Apr 17, 2018 at 9:21 AM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: > On Mon, Apr 16, 2018 at 08:05:44PM -0400, Olga Kornievskaia wrote: >> > On Apr 16, 2018, at 5:29 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: >> >> I believe what’s happening is that because the client hasn’t received >> >> CB_NULL that establishes a callback channel but got a CB_RECALL it’s >> >> just ignoring it. >> > >> > I see two succesful CB_NULL calls and replies, so I think the context >> > establishment worked. I don't know why there's a third CB_NULL in frame >> > 285. >> >> The two CB_NULL calls are both gss_init calls. They are not RPC NULL call. Server for some reason establishes 2 different gss context (again not necessarily a problem). The 3rd CB_NULL is gss_data and it sends an actual NULL call. I believe that’s the one that establishes a callback channel. > > Oh, I see. No, that NULL call isn't necessary. It's just the server > probing to see whether the callback channel works. That NULL call isn't > required by the spec and everything should still work if the CB_RECALL > is sent out before it completes. Ok thank you. Another question: can the nfsd decide to give out delegation regardless of the existence of the callback path? Looking at the nfsd open code I see that it checks if cl_cb_state is NFSD4_CB_UP. But I guess somehow (according to this trace), it finds it up? Any ideas, looks like a bug... On this particular network trace, in frame 240, the server gives out the read delegation (which is later on it's trying to recall). However the setup of the callback path(s) doesn't happen until frames 259/261 (tcp connections are established starting from frames 253/256). Goal is to try and reproduce this problem where the client is failing the CB_RECALL... but so far I can't trigger this. Also I figured out why there are 2 SETCLIENTIDs and it's not because of the 2 mounts (with unmount in the middle). First SETCLIENTID is trunking discovery. Second SETCLIENTID is for when client is trying to do an operation requiring a clientid. Therefore this leads to existence of 2 callback paths (ie 2 CB_NULL gss context establishment). I'm not sure if this is somehow incorrect that client provides 2 callback path and server establishes context for both. -- 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
