On Fri, Apr 12, 2013 at 09:49:39PM +0000, Myklebust, Trond wrote: > > -----Original Message----- > > From: nfsv4-bounces@xxxxxxxx [mailto:nfsv4-bounces@xxxxxxxx] On Behalf > > Of J. Bruce Fields > > Sent: Friday, April 12, 2013 5:01 PM > > To: nfsv4@xxxxxxxx > > Cc: linux-nfs@xxxxxxxxxxxxxxx > > Subject: [nfsv4] unsupported mandatory server features > > > > I'm expecting to turn on basic 4.1 support by default on the Linux server > > before supporting two mandatory 4.1 features, and looking for advice on > > handling that without too much pain to future clients. I suspect I'm not the > > only server in this situation; anyone know what others are doing? > > > > The features are: > > > > - State protection (SSV and MACH_CRED): I'm currently returning > > SERVERFAULT on EXCHANGE_ID's that request this, but this isn't > > really what SERVERFAULT is for. > > > > I'm inclined to switch to ENC_ALG_UNSUPP; that leaves future > > clients unable to distinguish between servers lacking SSV > > entirely from those lacking support for a particular > > algorithm, but in practice I think they'd handle both in the > > same way anyway. > > Why not just reply with NFS4ERR_ENC_ALG_UNSUPP for SP4_SSV (as you suggest) and return an empty spo_must_allow, and minimal spo_must_enforce sets for SP4_MACH_CRED? > > By minimal spo_must_enforce, I mean EXCHANGE_ID, CREATE_SESSION, DESTROY_SESSION, BIND_CONN_TO_SESSION, and DESTROY_CLIENTID. I'm assuming that you default to checking the principal name for those anyway since NFSv4 requires it for the corresponding SETCLIENTID/CONFIRM? Yes, I think you're right, I'll try that now! > > > - GSS on the backchannel: currently CREATE_SESSION or > > BACKCHANNEL_CTL will succeed but SEQUENCE will start returning > > with the CB_DOWN flag set. I would rather return an error > > immediately than make the client guess what's going on in > > recovery. > > > > Could I get away with returning ENC_ALG_UNSUPP here too? It's > > not entirely logical, but it's also currently illegal for > > these two operations so its use wouldn't be confused with some > > other. > > Why not return NFS4ERR_NOENT to tell the client that the handle does not exist? Imagine a client and server both support gss on the backchannel. The most likely cause I can think of (bugs aside) for a NFS4ERR_NOENT return in that case is that the server just purged that context from its cache for some reason. It would then seem reasonable for the client to attempt to recover by establishing a new context and resending with the new handle. How would the client distinguish between that case and "sorry, gss on the backchannel will never work"? I guess if the server was replying NOENT to a handle over which that very call was sent then maybe it'd be safe for the client to assume the latter case. It seems a little subtle. --b. -- 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
