Linus:
I've found a reproducible situation where an inode passed to
"clean_inode" has its "i_writecount" set to -1. As a result, the file
that's unfortunate enough to get the new inode gives ETXTBSY for any
subsequent open.
As I say, I can reproduce the situation. (The Debian boot sequence
triggers it.) However, I haven't been able to narrow down exactly
which "i_writecount--" doesn't have a matching "i_writecount++".
If you think its important that "i_writecount" be 0 when an inode is
freed, then I can spend some time tracking down the culprit. If not,
the enclosed, obvious patch against pre-patch-2.1.45 fixes the
problem. (It also gets rid of a spurious bit of fluff in "dcache.c".)
Kevin <buhr@stat.wisc.edu>
--Multipart_Thu_Jul_10_14:18:01_1997-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="fs.patches"
Content-Transfer-Encoding: 7bit
Index: linux/fs/dcache.c
diff -u linux/fs/dcache.c:1.1.1.2 linux/fs/dcache.c:1.1.1.2.2.1
--- linux/fs/dcache.c:1.1.1.2 Wed Jul 9 14:37:51 1997
+++ linux/fs/dcache.c Thu Jul 10 13:59:07 1997
@@ -350,10 +350,9 @@
static inline void d_remove_old_parent(struct dentry * entry)
{
struct dentry * parent;
- struct inode * inode;
parent = entry->d_parent;
- inode = entry->d_inode;
+
_d_remove_from_parent(entry, parent);
}
Index: linux/fs/inode.c
diff -u linux/fs/inode.c:1.1.1.2.2.1 linux/fs/inode.c:1.1.1.2.2.2
--- linux/fs/inode.c:1.1.1.2.2.1 Wed Jul 9 14:59:57 1997
+++ linux/fs/inode.c Thu Jul 10 14:00:09 1997
@@ -301,6 +301,7 @@
inode->i_sock = 0;
inode->i_op = NULL;
inode->i_nlink = 1;
+ inode->i_writecount = 0;
memset(&inode->i_dquot, 0, sizeof(inode->i_dquot));
sema_init(&inode->i_sem, 1);
}
--Multipart_Thu_Jul_10_14:18:01_1997-1--