On Fri, Apr 12, 2013 at 06:06:42PM -0400, J. Bruce Fields wrote: > 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! OK, OK, so the minimal SP4_MACH_CRED implementation is a lot easier than I thought: fs/nfsd/nfs4state.c | 62 ++++++++++++++++++++++++++++++++++++++++++--------- fs/nfsd/nfs4xdr.c | 2 +- fs/nfsd/state.h | 1 + 3 files changed, 53 insertions(+), 12 deletions(-) > > > - 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? I'm still inclined to return a new error here, though; NOENT seems already taken for something a client would handle a bit differently. --b. > > 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. -- 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
