On Sat, 10 Jul 2004, Thomas Moestl wrote: > Hello, > > On Sat, 2004/07/10 at 14:57:46 +0800, [EMAIL PROTECTED] wrote: > > > Hi, > > > > > > after deploying an SMP machine at work, we started to experience Oopses > > > in file-system related code relatively frequently. Investigation > > > revealed that they were caused by references using junk pointers from > > > freed super blocks via dangling inodes from unmounted file systems; > > > Oopses would always be preceded by the warning > > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... > > > on an unmount (unmount activity is high on this machine due to heavy use > > > of the automounter). The predecessor to this machine, a UP system with > > > otherwise almost identical configuration, did never encounter such > > > problems, so I went looking for possible SMP races. > > > > This has been reported many times by users of autofs, especially people > > with a ot of mount/umount activity. > > > > As James pointed out my latest autofs4 patch resolved the issue for him. > > However, on the NFS list Greg Banks pointed out that this may be hiding a > > problem that exists in NFS. So it would be good if the NFS folk could > > investigate this further. > > > > Never the less I'm sure there is a race in waitq.c of autofs4 in > > 2.4 that seems to cause this problem. This is one of the things > > addressed by my patch. > > The system in question still uses autofs3. While I believe that the > waitq race is also present there (it could probably cause directory > lookups to hang, if I understand it correctly), I do not think that > any autofs3 code could cause exactly those symptoms that I have > observed. For that, it would have to obtain dentries of the file > systems that it has mounted, but the old code never does that.
All autofs has to do is not delete a directory before exiting for this error to occur. Ian _______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
