Re: ext3_orphan_del may double-decrement bh->b_count

[Andrew Morton]

Chris Mason <mason@xxxxxxxx> wrote:
>
> > You need the buffer-tracing patch.  This is against 2.6.7-rc2.  It should
>  > spit a nice trace when you hit the problem.  It'll tell us how that buffer
>  > got itself not uptodate.
> 
>  Thanks.  jeffm had worked out something similar that stored the EIP of
>  each bit operation, the uptodate bit seems to have turned off all on its
>  own.  Once we can reproduce reliably on local boxes, we'll start
>  layering on the debugging code.  

buffer-trace code is what you need - it records the bh's internal state in
its trace buffer too, replays it all when you hit an assertion failure.

>  No triggers yet, I might have to grab a bigger machine in the morning.

Is direct-io involved?  I just discovered that clean_blockdev_aliases() is
invalidating too many blocks.  It tends to munch those indirect blocks. 
(What does bonnie++'s -f option do?)



diff -puN fs/direct-io.c~direct-io-invalidation-fix fs/direct-io.c
--- 25/fs/direct-io.c~direct-io-invalidation-fix	2004-06-02 19:29:29.300623696 -0700
+++ 25-akpm/fs/direct-io.c	2004-06-02 19:30:31.404182520 -0700
@@ -690,8 +690,11 @@ out:
 static void clean_blockdev_aliases(struct dio *dio)
 {
 	unsigned i;
+	unsigned nblocks;
 
-	for (i = 0; i < dio->blocks_available; i++) {
+	nblocks = dio->map_bh.b_size >> dio->inode->i_blkbits;
+
+	for (i = 0; i < nblocks; i++) {
 		unmap_underlying_metadata(dio->map_bh.b_bdev,
 					dio->map_bh.b_blocknr + i);
 	}
_

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