Re: RFC: Bug in generic_forget_inode() ?

[Herbert Xu]

Russ Weight <rweight@xxxxxxxxxx> wrote:
> 
> The problem is more likely in generic_forget_inode(). It releases the

Exactly.  It's a continuation of the greased turkey bug :)

When we're writing the inode out, we shouldn't place it on the unused
list at all.  Placing the inode on the unused list only makes sense
when we return from generic_forget_inode without actually destroying
the inode.

So we need something like this.  I'm not sure about the nr_unused
counter though.  Should we be incrementing it as we do now even when
we don't put the inode on the unused list?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
===== fs/inode.c 1.144 vs edited =====
--- 1.144/fs/inode.c	2005-03-05 17:41:15 +11:00
+++ edited/fs/inode.c	2005-03-19 11:11:56 +11:00
@@ -1037,12 +1037,14 @@
 	struct super_block *sb = inode->i_sb;
 
 	if (!hlist_unhashed(&inode->i_hash)) {
-		if (!(inode->i_state & (I_DIRTY|I_LOCK)))
-			list_move(&inode->i_list, &inode_unused);
 		inodes_stat.nr_unused++;
-		spin_unlock(&inode_lock);
-		if (!sb || (sb->s_flags & MS_ACTIVE))
+		if (!sb || (sb->s_flags & MS_ACTIVE)) {
+			if (!(inode->i_state & (I_DIRTY|I_LOCK)))
+				list_move(&inode->i_list, &inode_unused);
+			spin_unlock(&inode_lock);
 			return;
+		}
+		spin_unlock(&inode_lock);
 		write_inode_now(inode, 1);
 		spin_lock(&inode_lock);
 		inodes_stat.nr_unused--;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/