>
>
> On Tue, 5 Jan 1999, Alexander Viro wrote:
> >
> > The first entry was dropped, right, but it still remains our cwd.
> > So cd .. should get rid of it. Looks like it didn't.
>
> Right, and that sounds like a bug. A the last dput() of a non-hashed
> dentry should make the dentry go away, and we _shouldn't_ have any inode
> with a double count.
>
> I wonder if maybe vfat (or even the VFS layer) has a dentry count leak
> somewhere, so that the "last" dput() doesn't actually see a d_count of
> zero because something else forgot to decrement it..
Linus, I suspect that it may be vfat_rename bug resurfaced. 131
changed drop_replace_inodes() and this change introduced a leak in
rename(). I suspect that other calls of drop_replace_inodes() may also
be affected. My fault - I've fixed one place and didn't check the rest.
Anyway, I'm *very* suspicious about changes in vfat_rmdir - we oughtta
d_delete() the victim there. Not done. vfat_unlink() looks better, so
it may be something else. I'm not on the Linux box right now, but I'll
be there in an hour.
At least bit in vfat_rmdir() looks like a bug for me. Patch:
--- namei.c Fri Dec 18 10:09:36 1998
+++ namei.c.new Tue Jan 5 18:24:14 1999
@@ -1549,8 +1549,10 @@
res = -EBUSY;
if (list_empty(&dentry->d_hash)) {
res = vfat_rmdirx(dir, dentry);
- if (res >= 0)
+ if (res >= 0) {
drop_replace_inodes(dentry, NULL);
+ d_delete(dentry);
+ }
}
return res;
}
All this aliases-related stuff looks ugly. Try
$ mkdir a.long
$ cd a~1.lon
$ mkdir b
$ cd b
$ mv ../../a.long .
... and watch the fun.
Gordon, do we *really* need to be able to open something by short
name? They introduce quite a lot of mess. BTW, example above "worked" the
same way before changes in 131.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/