On 2009-09-25 16:29, Trond Myklebust wrote: > On Fri, 2009-09-25 at 07:30 +0300, Benny Halevy wrote: >> Trond, >> >> Is the patch below acceptable? >> >> Benny > > I'm still not entirely happy with the idea that the state manager can > get into situations where it needs outside help, and you haven't really > explained to me the root cause of the scenario. > You said something about > > nfs4_create_server() > nfs4_init_session() > nfs4_recover_expired_lease() > nfs4_schedule_state_recovery() > # and the failure happens within the state engine > nfs4_proc_create_session() > nfs4_proc_get_lease_time() return -2 > > Where does that ENOENT come from? > > You said something about it being an error in OP_PUTROOTFH, but as far > as I can see, the only permitted errors for putrootfh are either session > related errors (which should be handled by the state machine), > NFS4ERR_DELAY (which should be handled by the state machine) and > NFS4ERR_WRONGSEC. So which error is generating your ENOENT? > That scenario is caused when the server's /etc/exports is badly configured, where the export entry for nfsv4 (fsid=0) exports a non-existing path. I agree that the server should not return ENOENT for PUTROOTFH as it contradicts the spec. NFS4ERR_SERVERFAULT seems more appropriate. The main reason for getting the failure from the state engine in nfsv4.1 is that we need to create a session before nfs4_path_walk in nfs4_create_server and we do that using the state manager. In the nfsv4.0 case we create no state at this point. Benny -- 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
