[PATCH] Re: BUG in rmdir changes

Mike Galbraith (mikeg@weiden.de)
Sat, 12 Dec 1998 11:51:58 +0100 (CET)


On Thu, 10 Dec 1998, Matthias Hanisch wrote:

> On Wed, 9 Dec 1998, H.J. Lu wrote:
>
> > > I've seen the same behavior and did some more investigations yesterday.
> > > The problem are the rmdir changes in the VFS introduced with 2.1.131.
> > >
> > > The busy devices are caused by the removal of an non-existant directory.
> > >
> > > Look at the following session:
> > >
> > > pingu:~# umount /tmp
> > > pingu:~# mount /tmp
> > > pingu:~# rmdir /tmp/aaaaaaaaaaaaaaaa
> > > rmdir: /tmp/aaaaaaaaaaaaaaaa: No such file or directory
> > > pingu:~# umount /tmp
> > > umount: /tmp: device is busy
> > >
> > > I've put some printk's in the umount code and it seems that the root
> > > dentry has d_count = 2 at umount -> BUSY.
> > >
> > > This is with vanilla 2.1.131 and 2.1.131ac4, I've not tried later
> > > ac-patches.
> > >
> >
> > Does it work with 2.1.130?
>
> 2.1.130 doesn't have this problem and I've done a quick check with
> 2.1.131ac6 and the above behavior remains.
>
> I just want to mention that the above problem is NOT caused by dynamic
> linking together with ldconfig because I've relinked init with the "rpath"
> feature so ld.so.cache isn't touched.
>
> By the way this problem is reproducable with every mounted partition (even
> MSDOS filesystems) so there must be something wrong in the VFS rmdir code.
>
> Am I the only poor soul that sees this problem?

No, I see it too. Staring at the changes which let do this, it looks
like a couple of dputs got left behind for this error case. I tested
the below on ext2 and knfs.. all seems fine now.

It would be nice if a dcache-smart person would look at this 'fix'.

--- linux-2.1.131.virgin/fs/namei.c Thu Dec 10 15:37:04 1998
+++ linux-2.1.131.work/fs/namei.c Sat Dec 12 10:44:09 1998
@@ -880,7 +880,11 @@

error = -ENOENT;
if (!dentry->d_inode)
+ {
+ dput(dentry);
+ dput(dir);
goto exit;
+ }
/*
* The dentry->d_count stuff confuses d_delete() enough to
* not kill the inode from under us while it is locked. This

-Mike

-
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/