On Fri, Sep 25, 2009 at 04:53:17PM +0300, Benny Halevy wrote: > 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. So is there any actual client-side bug here? --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
