On Wed, Jun 05, 2013 at 04:19:34PM +1000, NeilBrown wrote: > On Wed, 5 Jun 2013 04:41:15 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, Jun 05, 2013 at 01:05:41PM +1000, NeilBrown wrote: > > > > > > Hi Bruce, > > > this is a little issue that seems to keep coming up so I thought it might be > > > time to fix it. > > > > > > As you know, a filesystem that is exported cannot be unmounted as the export > > > cache holds a reference to it. Though if it hasn't been accessed for a > > > while then it can. > > > > > > As I hadn't realised before sometimes *non* exported filesystems can be > > > pinned to. A negative entry in the cache can pin a filesystem just as > > > easily as a positive entry. > > > An amusing, if somewhat contrived, example is that if you export '/' with > > > crossmnt and: > > > > > > mount localhost:/ /mnt > > > ls -l / > > > umount /mnt > > > > > > the umount might fail. This is because the "ls -l" tried to export every > > > filesystem found mounted in '/'. The export of "/mnt" failed of course > > > because you cannot re-export an NFS filesystem. But it is still in the > > > cache. > > > An 'exportfs -f' fixes this, but shouldn't be necessary. Yeah, ugh. As a less contrived example, can the default v4 root export lead to arbitrary filesystems being pinned just because a client tried to mount the wrong path? Could the export cache be indexed on a path string instead of a struct path? The problem of negative entries aside, anyone counting on the ability to unexport mounted filesystems on a running nfs server is setting themselves up for trouble: suppose we fix this problem, what if an rpc is in progress, or a lock or v4 open or delegation is held? --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
