u-boot.git/fs, branch v2020.07-rc2

fs: ext4: avoid NULL check before free()

2020-05-01T15:34:01Z

free() checks if its argument is NULL. Don't duplicate this in the calling code. Signed-off-by: Heinrich Schuchardt

fs: ext4: skip journal state if fs has metadata_csum

2020-04-27T18:55:29Z

As u-boot doesn't support the metadata_csum feature, writing to a filesystem with this feature enabled will fail, as expected. However, during the process, a journal state check is performed, which could result in: - a fs recovery if the fs wasn't umounted properly - the fs being marked dirty Both these cases result in a superblock change, leading to a mismatch between the superblock checksum and its contents. Therefore, Linux will consider the filesystem heavily corrupted and will require e2fsck to be run manually to boot. By bypassing the journal state check, this patch ensures the superblock won't be corrupted if the filesystem has metadata_csum feature enabled. Signed-off-by: Arnaud Ferraris

fs: btrfs: support sparse extents

2020-04-20T16:23:29Z

When logical address of a regular extent is 0, the extent is sparse and consists of all zeros. Without this when sparse extents are used in a file reading fails with Cannot map logical address 0 to physical Signed-off-by: Marek Behún

fs: btrfs: Fix LZO false decompression error caused by pending zero

2020-04-17T02:13:50Z

For certain btrfs files with compressed file extent, uboot will fail to load it: btrfs_read_extent_reg: disk_bytenr=14229504 disk_len=73728 offset=0 nr_bytes=131 072 decompress_lzo: tot_len=70770 decompress_lzo: in_len=1389 decompress_lzo: in_len=2400 decompress_lzo: in_len=3002 decompress_lzo: in_len=1379 decompress_lzo: in_len=88539136 decompress_lzo: header error, in_len=88539136 clen=65534 tot_len=62580 NOTE: except the last line, all other lines are debug output. Btrfs lzo compression uses its own format to record compressed size (segment header, LE32). However to make decompression easier, we never put such segment header across page boundary. In above case, the xxd dump of the lzo compressed data looks like this: 00001fe0: 4cdc 02fc 0bfd 02c0 dc02 0d13 0100 0001 L............... 00001ff0: 0000 0008 0300 0000 0000 0011 0000|0000 ................ 00002000: 4705 0000 0001 cc02 0000 0000 0000 1e01 G............... '|' is the "expected" segment header start position. But in that page, there are only 2 bytes left, can't contain the 4 bytes segment header. So btrfs compression will skip that 2 bytes, put the segment header in next page directly. Uboot doesn't have such check, and read the header with 2 bytes offset, result 0x05470000 (88539136), other than the expected result 0x00000547 (1351), resulting above error. Follow the btrfs-progs restore implementation, by introducing tot_in to record total processed bytes (including headers), and do proper page boundary skip to fix it. Please note that, current code base doesn't parse fs_info thus we can't grab sector size easily, so it uses PAGE_SIZE, and relying on fs open time check to exclude unsupported sector size. Signed-off-by: Qu Wenruo Cc: Marek Behun Reviewed-by: Marek Behún

fs: btrfs: Reject fs with sector size other than PAGE_SIZE

2020-04-17T02:13:50Z

Although in theory u-boot fs driver could easily support more sector sizes, current code base doesn't have good enough way to grab sector size yet. This would cause problem for later LZO fixes which rely on sector size. And considering that most u-boot boards are using 4K page size, which is also the most common sector size for btrfs, rejecting fs with non-page-sized sector size shouldn't cause much problem. This should only be a quick fix before we implement better sector size support. Signed-off-by: Qu Wenruo Cc: Marek Behun Reviewed-by: Marek Behún

fs: btrfs: Use LZO_LEN to replace immediate number

2020-04-17T02:13:50Z

Just a cleanup. These immediate numbers make my eyes hurt. Signed-off-by: Qu Wenruo Cc: Marek Behun Reviewed-by: Marek Behún

fs: ext4: Fix alignment of cache buffers

2020-03-27T19:42:04Z

We need to align the cache buffer to ARCH_DMA_MINALIGN in order to avoid access errors like CACHE: Misaligned operation at range [be0231e0, be0235e0] seen on the MCIMX7SABRE. Fixes: d5aee659f217 ("fs: ext4: cache extent data") Signed-off-by: Jan Kiszka Reviewed-by: Tom Rini Reviewed-by: Stephen Warren Tested-by: Peter Robinson

Merge tag 'dm-pull-6feb20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm

2020-02-11T15:58:41Z

sandbox conversion to SDL2 TPM TEE driver Various minor sandbox video enhancements New driver model core utility functions

fat: write: adjust data written in each partial write

2020-02-07T18:59:58Z

The code for handing file overwrite incorrectly calculated the amount of data to write when writing to the last non-cluster aligned chunk. Fix this by ensuring that no more data than the 'filesize' is written to disk. While touching min()-based calculations, change it to type-safe min_t() function. Signed-off-by: Marek Szyprowski This patch finally fixes the issue revealed by the test script from the previous patch. The correctness of the change has been also verified by the following additional test scripts: --->8-fat_test2.sh--- #!/bin/bash make sandbox_defconfig make dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k mkfs.vfat -v /tmp/10M.img cat >/tmp/cmds </tmp/model/file0001.raw yes ABC | head -c 4096 >/tmp/model/file0003.raw yes ABC | head -c 4096 >/tmp/model/file0005.raw yes DEF | head -c 7936 >/tmp/model/file0007.raw mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result hd /tmp/10M.img if diff -urq /tmp/model /tmp/result then echo Test okay else echo Test fail fi --->8-fat_test3.sh--- #!/bin/bash make sandbox_defconfig make dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k mkfs.vfat -v /tmp/10M.img cat >/tmp/cmds </tmp/model/file0001.raw yes ABC | head -c 4096 >/tmp/model/file0003.raw yes ABC | head -c 4096 >/tmp/model/file0005.raw yes DEF | head -c 8448 >/tmp/model/file0007.raw mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result hd /tmp/10M.img if diff -urq /tmp/model /tmp/result then echo Test okay else echo Test fail fi --->8-fat_test4.sh--- #!/bin/bash make sandbox_defconfig make dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k mkfs.vfat -v /tmp/10M.img cat >/tmp/cmds </tmp/model/file0001.raw yes ABC | head -c 4096 >/tmp/model/file0003.raw yes ABC | head -c 4096 >/tmp/model/file0005.raw yes DEF | head -c 2304 >/tmp/model/file0007.raw yes GHI | head -c 2304 >>/tmp/model/file0007.raw yes DEF | head -c 2304 >>/tmp/model/file0007.raw yes GHI | head -c 2304 >>/tmp/model/file0007.raw mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result hd /tmp/10M.img if diff -urq /tmp/model /tmp/result then echo Test okay else echo Test fail fi --->8--- Feel free to prepare a proper sandbox/py_test based tests based on the provided test scripts.

fat: write: fix broken write to fragmented files

2020-02-07T18:59:58Z

The code for handing file overwrite incorrectly assumed that the file on disk is always contiguous. This resulted in corrupting disk structure every time when write to existing fragmented file happened. Fix this by adding proper check for cluster discontinuity and adjust chunk size on each partial write. Signed-off-by: Marek Szyprowski This patch partially fixes the issue revealed by the following test script: --->8-fat_test1.sh--- #!/bin/bash make sandbox_defconfig make dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k mkfs.vfat -v /tmp/10M.img cat >/tmp/cmds </tmp/model/file0001.raw yes ABC | head -c 4096 >/tmp/model/file0003.raw yes ABC | head -c 4096 >/tmp/model/file0005.raw yes DEF | head -c 16384 >/tmp/model/file0007.raw mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result hd /tmp/10M.img if diff -urq /tmp/model /tmp/result then echo Test okay else echo Test fail fi --->8--- Overwritting a discontiguous test file (file0007.raw) no longer causes corruption to file0003.raw, which's data lies between the chunks of the test file. The amount of data written to disk is still incorrect, what causes damage to the file (file0005.raw), which's data lies next to the test file. This will be fixed by the next patch. Feel free to prepare a proper sandbox/py_test based tests based on the provided test scripts.