]> git.sur5r.net Git - u-boot/commit
fs:ext4:write:fix: Reinitialize global variables after updating a file
authorŁukasz Majewski <l.majewski@samsung.com>
Tue, 6 May 2014 07:36:05 +0000 (09:36 +0200)
committerTom Rini <trini@ti.com>
Mon, 12 May 2014 20:31:50 +0000 (16:31 -0400)
commit8b454eeeea0ba021ee27f3e103daf1f8fa87bd16
tree7aea0d65b3a11b11181e700b1a4053189209a819
parent35dd055b94eb3ed8c21595eedd740431866b2f26
fs:ext4:write:fix: Reinitialize global variables after updating a file

This bug shows up when file stored on the ext4 file system is updated.

The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
data.
However some global data (especially ext4fs_indir2_block), which is used
during file deletion are left unchanged.

The ext4fs_indir2_block pointer stores reference to old ext4 double
indirect allocated blocks. When it is unchanged, after file deletion,
ext4fs_write_file() uses the same pointer (since it is already initialized
- i.e. not NULL) to return number of blocks to write. This trunks larger
file when previous one was smaller.

Lets consider following scenario:

1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
2. Developer wants to upload their custom uImage [**]
- When new uImage [**] is smaller than the [*] - everything works
correctly - we are able to store the whole smaller file with corrupted
ext4fs_indir2_block pointer
- When new uImage [**] is larger than the [*] - theCRC is corrupted,
since truncation on data stored at eMMC was done.
3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
proper setting of ext4fs_indir2_block() and after that uImage[**]
is successfully stored (correct uImage [*] metadata is stored at an
eMMC on the first flashing).

Due to above the bug was very difficult to reproduce.
This patch sets default values for all ext4fs_indir* pointers/variables.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
fs/ext4/ext4_common.c
fs/ext4/ext4_write.c
include/ext4fs.h