ext4: Correct block number handling, empty block vs. error code
authorStefan Brüns <stefan.bruens@rwth-aachen.de>
Tue, 6 Sep 2016 02:36:55 +0000 (04:36 +0200)
committerTom Rini <trini@konsulko.com>
Fri, 23 Sep 2016 13:02:44 +0000 (09:02 -0400)
commitde9e831675d72c08c2cc3361a8e9b413ff3facec
tree174bdeba3cc3ddeb6766bdf652aec0da4f55e4f6
parentb779e0290a4a6ac589bfac7192b4f8e677d3bf8a
ext4: Correct block number handling, empty block vs. error code

read_allocated block may return block number 0, which is just an indicator
a chunk of the file is not backed by a block, i.e. it is sparse.

During file deletions, just continue with the next logical block, for other
operations treat blocknumber <= 0 as an error.

For writes, blocknumber 0 should never happen, as U-Boot always allocates
blocks for the whole file.  Reading already handles this correctly, i.e. the
read buffer is 0-fillled.

Not treating block 0 as sparse block leads to FS corruption, e.g.
./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
ext4write host 0 0 /2.5GB.file 1 '
The 2.5GB.file from the fs test is actually a sparse file.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
fs/ext4/ext4_common.c
fs/ext4/ext4_write.c