Commit Graph

5 Commits

Author SHA1 Message Date
Al Viro
117aff744a Fix autofs_expire()
mnt should remain the same for all iterations through the list;
as it is, if we have a busy mount, mnt follows into it and isn't
restored for the next iteration.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2009-04-20 23:01:15 -04:00
David Howells
0e7d73824e [PATCH] autofs3: Make sure all dentries refs are released before calling kill_anon_super()
Make sure all dentries refs are released before calling kill_anon_super()
so that the assumption that generic_shutdown_super() can completely destroy
the dentry tree for there will be no external references holds true.

What was being done in the put_super() superblock op, is now done in the
kill_sb() filesystem op instead, prior to calling kill_anon_super().

The call to shrink_dcache_sb() is removed as it is redundant since
shrink_dcache_for_umount() will now be called after the cleanup routine.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Ian Kent <raven@themaw.net>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20 10:26:38 -07:00
Ian Kent
e3474a8eb3 [PATCH] autofs4: change may_umount* functions to boolean
Change the functions may_umount and may_umount_tree to boolean functions to
aid code readability.

Signed-off-by: Ian Kent <raven@themaw.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27 08:44:40 -08:00
Alexander Krizhanovsky
f76baf9365 [PATCH] autofs: fix "busy inodes after umount..."
This patch for old autofs (version 3) cleans dentries which are not putted
after killing the automount daemon (it's analogue of recent patch for
autofs4).

Signed-off-by: Alexander Krizhanovsky <klx@yandex.ru>
Cc: Ian Kent <raven@themaw.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:57:31 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00