On 07/23/2018 04:09 PM, Tom Rini wrote:
> On Mon, Jul 23, 2018 at 11:42:12AM +0200, Marek Vasut wrote:
>
>> The variable 'n' represents the number of bytes to be read from a certain
>> offset in a file, to a certain offset in buffer 'buf'. The variable 'len'
>> represents the length of the entire file, clamped correctly to avoid any
>> overflows.
>>
>> Therefore, comparing 'n' and 'len' to determine whether clearing 'n'
>> bytes of the buffer 'buf' at a certain offset would clear data past
>> buffer 'buf' cannot lead to a correct result, since the 'n' does not
>> contain the offset from the beginning of the file.
>>
>> This patch keeps track of the amount of data read and checks for the
>> buffer overflow by comparing the 'n' to the remaining amount of data
>> to be read instead.
>>
>> Signed-off-by: Marek Vasut <ma...@denx.de>
>> Cc: Ian Ray <ian....@ge.com>
>> Cc: Martyn Welch <martyn.we...@collabora.co.uk>
>> Cc: Stefano Babic <sba...@denx.de>
>> Cc: Tom Rini <tr...@konsulko.com>
>> Fixes: ecdfb4195b20 ("ext4: recover from filesystem corruption when reading")
>
> Good catch. Can this problem also be recreated/tested with
> test/fs/fs-test.sh? Thanks!
>
I think so. I'd memalign() a buffer with some safe space around it, ie.
a 4k page on each side and poison it with a pattern. I'd then read a
file which is not ext4 FS block size aligned into 1-page offset from the
beginning of that buffer . Finally, I'd check if exactly the size of the
file was changed in that buffer and the poisoned area of the buffer
still contains the poison or not.
|................poison................|
|
v
|...poison...|file...|.DZ.|...poison...|
If DZ is poison, everything is OK.
If DZ is 0x0, the ext4 corruption happened.
--
Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
