Re: [PATCH v2 4/4] udf: don't use eloc after the end of the unallocated space table

[Jan Kara]

> When udf_next_aext() returns 0, its eloc, elen and etype outputs hold
> no defined value.  Two walks of the unallocated space table still use
> eloc after the walk has reached the end of the table.
> 
> udf_table_prealloc_blocks() looks for a free extent starting at
> first_block and decides whether it found one by comparing eloc with
> first_block after the walk.  If the table's list ends in a continuation
> descriptor that leads to an empty allocation extent, eloc is then the
> block of that allocation extent, which is in use, and if that is
> first_block, the block is handed out as preallocation.  Once
> udf_discard_prealloc() no longer frees the wrong block, this is what
> still makes fsx in generic/091 and generic/263 read back bad data on a
> table, in about one run in four.  Only take the extent if the walk
> stopped at it.
> 
> When udf_table_free_blocks() cannot merge the freed blocks into an
> existing extent, it appends a new one and sets only its block number,
> so the partition reference comes from whatever eloc held after the
> walk, and with long allocation descriptors it is written to disk.  For
> a table without extents, eloc was never set.  Take the partition
> reference from the freed blocks instead.  Short allocation descriptors
> do not store the partition reference, which is why this half remains a
> latent long-descriptor fix rather than a reproduced failure.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Matthias Goergens <matthias.goergens@xxxxxxxxx>
...
> @@ -532,7 +533,7 @@ static int udf_table_prealloc_blocks(struct super_block *sb,
>  			  eloc.logicalBlockNum, elen, first_block);
>  	}
>  
> -	if (first_block == eloc.logicalBlockNum) {
> +	if (ret > 0 && first_block == eloc.logicalBlockNum) {

AFAICS we can actually make this simpler by just jumping to err_out if
ret == 0 instead of just breaking out of the loop. I'll improve this on
commit.

								Honza

-- 
Jan Kara <jack@xxxxxxx>