On Sat, Sep 24, 2005 at 01:14:31PM +0100, Chris Sykes wrote:
> After many compile reboot cycles, git-bisect tells me that the
> offending cset is 10f47e6a1b8b276323b652053945c87a63a5812d:
>     [PATCH] ext2: Enable atomic inode security labeling
> 
> I'll do some more testing to verify.

Latest kernel from git (2.6.14-rc2-g87e807b6) still causes the problem
for me.  Reversing cset 10f47e6a1b8b276323b652053945c87a63a5812d fixes
it for me.

I'll build a kernel with CONFIG_EXT2_FS_XATTR disabled and see if that
also makes the issue go away.

I have a question though.  When looking at the code in
fs/ext2/ialloc.c for ext2_new_inode().  The failure path for
ext2_init_acl() includes a DQUOT_DROP(), but the failure path for
ext2_init_security() does not. e.g.:

        err = ext2_init_acl(inode, dir);
        if (err) { 
                DQUOT_FREE_INODE(inode);
                DQUOT_DROP(inode);
                goto fail2;
        }
        err = ext2_init_security(inode,dir);
        if (err) { 
                DQUOT_FREE_INODE(inode);
                goto fail2;
        }

Is this right?  Or should we really have the following:

Signed-off-by: Chris Sykes <chris@sigsegv.plus.com>

diff --git a/fs/ext2/ialloc.c b/fs/ext2/ialloc.c
--- a/fs/ext2/ialloc.c
+++ b/fs/ext2/ialloc.c
@@ -618,6 +618,7 @@ got:
 	err = ext2_init_security(inode,dir);
 	if (err) {
 		DQUOT_FREE_INODE(inode);
+		DQUOT_DROP(inode);
 		goto fail2;
 	}
 	mark_inode_dirty(inode);


-- 

(o-  Chris Sykes
//\       "Don't worry. Everything is getting nicely out of control ..."
V_/_                          Douglas Adams - The Salmon of Doubt
GPG Fingerprint: 5E8E D17F F96C CC08 911D  CAF2 9049 70D8 5143 8090