On Sat, 22 Oct 2005, Jim Carter wrote: > On Sat, 22 Oct 2005, Ian Kent wrote: > > > It appears that there is a situation in which autofs thinks the lock > > is still held when it is not. A race (no doubt) or maybe a missing test in > > the wait. So my feeling of wanting to eliminate the locking returns again. > > Sorry. > > Agreed that problems in mount's lock should be fixed, but my diagnosis of > the autofs situation went like this: it acquires its lock, then it tries to > do a nested automount, and the nested instance can't get the lock. I > suggested statting the referent in advance, to trigger the nested mount > ahead of time. Autofs might do this: if it decides (before acquiring the > mount) that it's going to do a bind mount, then it stats the referent, > triggering nested automount(s) if any. Would it disrupt the logic too much > to recognize the bind mount before getting the lock?
Yes. I think that is an innovative way to use program maps indeed and should work. But would be a little difficult to write for some. The other reason that this is a hot issue for me is that as, Mike Jagdis points out, the locking as is will block all NFS mounts to all servers if mount hangs on a broken server. I know a lot of work has gone into code to check that a server is available before mounting but mount could still hang for some other reason. > > If we trust mount's lock, and don't do locking in autofs, I wonder if > nested automounts would put mount into exactly the same deadlock that > autofs is getting into now? I don't think so because in mount the lock is used to update the mtab after the mount has been completed. This won't trigger a further mount. The problem is the broad scope of the lock when used in autofs. Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
