On Wed, 2013-06-26 at 15:20 -0400, Steve Dickson wrote: > > On 18/06/13 15:59, Myklebust, Trond wrote: > >> -----Original Message----- > >> From: Christopher T Vogan [mailto:cvogan@xxxxxxxxxx] > >> Sent: Tuesday, June 18, 2013 3:56 PM > >> To: Myklebust, Trond > >> Cc: linux-nfs@xxxxxxxxxxxxxxx > >> Subject: Re: NFSERR_STALE on umount with 3.10.0.RC5 kernel > >> > >> The NFS server uses UMNT as a signal to remove the client from its mount > >> table. Also at this time the Server cleans up other information about the now > >> disconnected client. Why would the client attempt to access the NFS server > >> once it has stated its going to unmount? I do not see the point of the > >> GETATTR request after UMNT call. > > > > As I said, the umount.nfs utility is doing the umount system call after UMNT, so the > > client does a lookup of the umount path at that time. > > > > IOW: This has nothing to do with the kernel. If you feel it is a bug, then please ask > > SteveD to file a fix against nfs-utils. > > > I just took a look at the umount code and it appears the UMNT call and > umount() system call are being done in the correct order... > > The UMNT call is done in nfs_umount23() which is follow by either > mnt_context_do_umount() (if using the libmount code) or del_mtab() > which make the umount() system call.... That's the order that will cause the result Christopher is seeing: first a UMNT call, then a lookup/revalidate as part of the umount() system call. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
