Re: [PATCH] Re: BUG in rmdir changes

H.J. Lu (hjl@lucon.org)
Sat, 12 Dec 1998 08:24:52 -0800 (PST)

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

THANKS. It is what I has been looking for. Here is a similar patch.
It is a little more efficient since we don't need to call dget if
the directory doesn't exist.

Thanks again.

H.J.
-----
Index: fs/namei.c
===================================================================
RCS file: /home/work/cvs/linux/linux/fs/namei.c,v
retrieving revision 1.1.1.27
diff -u -p -r1.1.1.27 namei.c
--- namei.c 1998/12/03 22:03:14 1.1.1.27
+++ namei.c 1998/12/12 16:22:14
@@ -876,11 +876,14 @@ static inline int do_rmdir(const char *
if (IS_ERR(dentry))
goto exit;

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

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