Subject: Re: [CHECKER] Transcation is not fully aborted upon failure in JFS
	(jfs 2.4, kernel 2.4.19)
From: Dave Kleikamp <shaggy@austin.ibm.com>
To: Junfeng Yang <yjf@stanford.edu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       JFS Discussion <jfs-discussion@www-124.southbury.usf.ibm.com>,
       mc@cs.Stanford.EDU, Madanlal S Musuvathi <madan@stanford.edu>,
       "David L. Dill" <dill@cs.Stanford.EDU>
In-Reply-To: <Pine.GSO.4.44.0404262349260.7369-100000@elaine24.Stanford.EDU>
References: <Pine.GSO.4.44.0404262349260.7369-100000@elaine24.Stanford.EDU>
Content-Type: text/plain
Message-Id: <1083353278.14140.52.camel@shaggy.austin.ibm.com>
Mime-Version: 1.0
Date: Fri, 30 Apr 2004 14:27:59 -0500
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1188
Lines: 30

On Tue, 2004-04-27 at 01:54, Junfeng Yang wrote:
> Hi,
> 
> We checked JFS filesystem on linux 2.4.19 recently and found 1 case that
> looks like bugs.
> 
> When doing jfs_rename, if dtDelete fails, the transaction won't be fully
> aborted (even if txAbort is called).

Looking back at an old version of the code, the original coder had the
kernel trap if dtDelete failed.  It really would be a rare case for
dtDelete to fail here.  I had changed the trap to the txAbort call to
make the unlikely failure a little more friendly.  I recognized that
everything wouldn't be completely consistent, so I had txAbort mark the
superblock dirty, which will force a complete fsck run before the volume
can be mounted again.

I can probably improve on this and leave the system in better
condition.  I'll treat this as a low priority bug.

Thanks for your work auditing the code and reporting the problem.
-- 
David Kleikamp
IBM Linux Technology Center

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