Date: Wed, 22 Sep 2004 08:29:25 +0100
From: viro@parcelfarce.linux.theplanet.co.uk
To: Andrew Morton <akpm@osdl.org>
Cc: Mingming Cao <cmm@us.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: [Patch] ext3_new_inode() failure case fix
Message-ID: <20040922072925.GH23987@parcelfarce.linux.theplanet.co.uk>
References: <200409071302.i87D2Dus030892@sisko.scot.redhat.com> <1095815041.1637.32926.camel@w-ming2.beaverton.ibm.com> <20040921230124.368e469c.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040921230124.368e469c.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1681
Lines: 42

On Tue, Sep 21, 2004 at 11:01:24PM -0700, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > While I am studying ext3_new_inode() failure code paths, I found the
> > inode->i_nlink is not cleared to 0 in the first failure path. But it is
> > cleared to 0 in the second failure path(fail to allocate disk quota). I
> > think it should be cleared in both cases, because later when
> > generic_drop_inode() is called by iput(), i_nlink is checked to decide
> > whether to call generic_delete_inode(). Currently it is calling
> > generic_forget_inode().
> > 
> > Also the reference to the inode bitmap buffer head should be dropped on
> > the failure path too.
> 
> That reference already is dropped:
> 
> > --- linux-2.6.9-rc1-mm5/fs/ext3/ialloc.c~ext3_new_inode_failure_case_fix	2004-09-22 00:18:18.196012520 -0700
> > +++ linux-2.6.9-rc1-mm5-ming/fs/ext3/ialloc.c	2004-09-22 00:19:20.063607216 -0700
> > @@ -622,7 +622,9 @@ got:
> >  fail:
> >  	ext3_std_error(sb, err);
> >  out:
> > +	inode->i_nlink = 0;
> >  	iput(inode);
> > +	brelse(bitmap_bh);
> >  	ret = ERR_PTR(err);
> >  really_out:
> >  	brelse(bitmap_bh);
> 
>         ^ here
> 
> So I'll drop that part of the patch.

Drop it completely - we do *NOT* want ->delete_inode() to be called until
we had done allocation (and set sane ->i_ino, while we are at it).  And
that's exactly the difference between places that bail to fail2 and places
that bail to out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/