summaryrefslogtreecommitdiffstats
path: root/fs/autofs4
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] autofs4: fix infamous "Busy inodes after umount ..." messageIan Kent2005-07-272-0/+74
| | | | | | | | | | | | If the automount daemon receives a signal which causes it to sumarily terminate the autofs4 module leaks dentries. The same problem exists with detached mount requests without the warning. This patch cleans these dentries at umount. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] autofs4: mistake in debug printIan Kent2005-07-071-2/+2
| | | | | | | | Fix debugging printk. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] autofs4: bad lookup fixIan Kent2005-06-211-1/+8
| | | | | | | | | | | | | | | | | For browsable autofs maps, a mount request that arrives at the same time an expire is happening can fail to perform the needed mount. This happens becuase the directory exists and so the revalidate succeeds when we need it to fail so that lookup is called on the same dentry to do the mount. Instead lookup is called on the next path component which should be whithin the mount, but the parent isn't mounted. The solution is to allow the revalidate to continue and perform the mount as no directory creation (at mount time) is needed for browsable mount entries. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] autofs4: post expire race fixIan Kent2005-06-211-0/+7
| | | | | | | | | | | | | | At the tail end of an expire it's possible for a process to enter autofs4_wait, with a waitq type of NFY_NONE but find that the expire is finished. In this cause autofs4_wait will try to create a new wait but not notify the daemon leading to a hang. As the wait type is meant to delay mount requests from revalidate or lookup during an expire and the expire is done all we need to do is check if the dentry is a mountpoint. If it's not then we're done. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] autofs4: avoid panic on bind mount of autofs owned directoryIan Kent2005-06-213-5/+19
| | | | | | | | | | | While this is not a solution to bind and move mounts on autofs owned directories it is necessary to fix the trady error handling. At least it avoids the kernel panic I observed checking out bug #4589. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] autofs4: tree race fixIan Kent2005-05-013-4/+27
| | | | | | | | | | | | For tree mount maps, a call to chdir or chroot, to a directory above the moint point directories at a certain time during the expire results in the expire incorrectly thinking the tree is not busy. This patch adds a check to see if the filesystem above the tree mount points is busy and also locks the filesystem during the tree mount expire to prevent the race. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] autofs4: wait order fixIan Kent2005-05-012-10/+13
| | | | | | | | | | It's possible for an event wait request to arive before the event requestor. If this happens the daemon never gets notified and autofs hangs. Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-168-0/+2060
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud