From bad608633a3301f7b13339080a9d8f587adc9ba4 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 17 Sep 2010 16:00:15 +1000 Subject: [PATCH] add_block_address: be careful with physaddr == 0 An address of '0' is not consecutive with and address of '1' and while it is very unlikely to ever be a problem, make sure we don't try to combine those addresses into a range in the uninc table. Also remove a comment about a possible problem that doesn't seem to be a real problem. Signed-off-by: NeilBrown --- index.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/index.c b/index.c index d5adfe7..d1c4097 100644 --- a/index.c +++ b/index.c @@ -2016,6 +2016,7 @@ int lafs_add_block_address(struct fs *fs, struct block *blk) [p->uninc_table.pending_cnt-1]; if (p->uninc_table.pending_cnt >= 1 && a->fileaddr+a->cnt == blk->fileaddr && + a->physaddr != 0 && a->physaddr+a->cnt == blk->physaddr) { a->cnt++; if (test_and_clear_bit(B_UnincCredit, &blk->flags)) @@ -2165,11 +2166,7 @@ int lafs_allocated_block(struct fs *fs, struct block *blk, u64 phys) */ return 0; getref(blk, MKREF(uninc)); - /* FIXME if this block is beyond EOF, we might be about - * to invalidate it, so putting it on a list is a bad - * idea. We can just *know* that beyond EOF is - * truncated and not store the block.... maybe?? - */ + spin_lock(&blk->inode->i_data.private_lock); blk->chain = p->uninc_next; p->uninc_next = blk; -- 2.39.5