u-boot.git/fs/btrfs/inode.c, branch master

fs: btrfs: fix out of bounds write

2024-06-26T15:55:53+00:00

Fix btrfs_read/read_and_truncate_page write out of bounds of destination
buffer. Old behavior break bootstd malloc'd buffers of exact file size.
Previously this OOB write have not been noticed because distroboot usually
read files into huge static memory areas.

Signed-off-by: Alex Shumsky 
Fixes: e342718 ("fs: btrfs: Implement btrfs_file_read()")
Reviewed-by: Qu Wenruo

btrfs: fix some error checking for btrfs_decompress()

2023-08-08T21:41:52+00:00

The btrfs_decompress() function mostly (u32)-1 on error but it can
also return -EPERM or other kernel error codes from zstd_decompress().
The "ret" variable is an int, so we could just check for negatives.

Signed-off-by: Dan Carpenter 
Reviewed-by: Qu Wenruo

btrfs: fix offset when reading compressed extents

2023-05-08T13:23:53+00:00

btrfs_read_extent_reg correctly computed the extent offset in the
BTRFS_COMPRESS_NONE case, but did not account for the 'offset - key.offset'
part correctly in the compressed case, making the function read
incorrect data.

In the case I examined, the last 4k of a file was corrupted and
contained data from a few blocks prior, e.g. reading a 10k file with a
single extent:
btrfs_file_read()
 -> btrfs_read_extent_reg
    (aligned part loop, until 8k)
 -> read_and_truncate_page
   -> btrfs_read_extent_reg
      (re-reads the last extent from 8k to the end,
      incorrectly reading the first 2k of data)

This can be reproduced as follow:
$ truncate -s 200M btr
$ mount btr -o compress /mnt
$ pat() { dd if=/dev/zero bs=1M count=$1 iflag=count_bytes status=none | tr '\0' "\\$2"; }
$ { pat 4K 1; pat 4K 2; pat 2K 3; }  > /mnt/file
$ sync
$ filefrag -v /mnt/file
File size of /mnt/file is 10240 (3 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       2:       3328..      3330:      3:             last,encoded,eof
$ umount /mnt

Then in u-boot:
=> load scsi 0 2000000 file
10240 bytes read in 3 ms (3.3 MiB/s)
=> md 2001ff0
02001ff0: 02020202 02020202 02020202 02020202  ................
02002000: 01010101 01010101 01010101 01010101  ................
02002010: 01010101 01010101 01010101 01010101  ................

(02002000 onwards should contain '03' pattern but went back to 01,
start of the extent)

After patch, data is read properly:
=> md 2001ff0
02001ff0: 02020202 02020202 02020202 02020202  ................
02002000: 03030303 03030303 03030303 03030303  ................
02002010: 03030303 03030303 03030303 03030303  ................

Note that the code previously (before commit e3427184f38a ("fs: btrfs:
Implement btrfs_file_read()")) did not split that read in two, so
this is a regression even if the previous code might not have been
handling offsets correctly either (something that booted now fails to
boot)

Fixes: a26a6bedafcf ("fs: btrfs: Introduce btrfs_read_extent_inline() and btrfs_read_extent_reg()")
Signed-off-by: Dominique Martinet 
Reviewed-by: Qu Wenruo

treewide: Fix Marek's name and change my e-mail address

2022-07-21T08:14:04+00:00

Fix diacritics in some instances of my name and change my e-mail address
to kabel@kernel.org.

Add corresponding .mailmap entries.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese

btrfs: simplify lookup_data_extent()

2022-06-06T21:47:17+00:00

After returning if ret <= 0 we know that ret > 0. No need to check it.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Qu Wenruo 
Reviewed-by: Anand Jain

fs/btrfs: fix a bug that U-boot fs btrfs implementation doesn't handle NO_HOLE feature correctly

2022-01-18T13:31:02+00:00

[BUG]
When passing a btrfs with NO_HOLE feature to U-boot, and if one file
contains holes, then the hash of the file is not correct in U-boot:

 # mkfs.btrfs -f test.img	# Since v5.15, mkfs defaults to NO_HOLES
 # mount test.img /mnt/btrfs
 # xfs_io -f -c "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/btrfs/file
 # md5sum /mnt/btrfs/file
 277f3840b275c74d01e979ea9d75ac19  /mnt/btrfs/file
 # umount /mnt/btrfs
 # ./u-boot
 => host bind 0 /home/adam/test.img
 => ls host 0
 <   >      12288  Mon Dec 27 05:35:23 2021  file
 => load host 0 0x1000000 file
 12288 bytes read in 0 ms
 => md5sum 0x1000000 0x3000
 md5 for 01000000 ... 01002fff ==> 855ffdbe4d0ccc5acab92e1b5330e4c1

The md5sum doesn't match at all.

[CAUSE]
In U-boot btrfs implementation, the function btrfs_read_file() has the
following iteration for file extent iteration:

	/* Read the aligned part */
	while (cur < aligned_end) {
		ret = lookup_data_extent(root, &path, ino, cur, &next_offset);
		if (ret < 0)
			goto out;
		if (ret > 0) {
			/* No next, direct exit */
			if (!next_offset) {
				ret = 0;
				goto out;
			}
		}
		/* Read file extent */

But for NO_HOLES features, hole extents will not have any extent item
for it.
Thus if @cur is at a hole, lookup_data_extent() will just return >0, and
update @next_offset.

But we still believe there is some data to read for @cur for ret > 0
case, causing we read extent data from the next file extent.

This means, what we do for above NO_HOLES btrfs is:
- Read 4K data from disk to file offset [0, 4K)
  So far the data is still correct

- Read 4K data from disk to file offset [4K, 8K)
  We didn't skip the 4K hole, but read the data at file offset [8K, 12K)
  into file offset [4K, 8K).

  This causes the checksum mismatch.

[FIX]
Add extra check to skip to the next non-hole range after
lookup_data_extent().

Signed-off-by: Qu Wenruo

fs: btrfs: fix the false alert of decompression failure

2021-04-27T12:05:30+00:00

There are some cases where decompressed sectors can have padding zeros.

In kernel code, we have lines to address such situation:

        /*
         * btrfs_getblock is doing a zero on the tail of the page too,
         * but this will cover anything missing from the decompressed
         * data.
         */
        if (bytes < destlen)
                memset(kaddr+bytes, 0, destlen-bytes);
        kunmap_local(kaddr);

But not in U-boot code, thus we have some reports of U-boot failed to
read compressed files in btrfs.

Fix it by doing the same thing of the kernel, for both inline and
regular compressed extents.

Reported-by: Matwey Kornilov 
Link: https://bugzilla.suse.com/show_bug.cgi?id=1183717
Fixes: a26a6bedafcf ("fs: btrfs: Introduce btrfs_read_extent_inline() and btrfs_read_extent_reg()")
Signed-off-by: Qu Wenruo

fs: btrfs: inode: handle uninitialized type before returning it

2020-11-19T14:45:49+00:00

In btrfs_lookup_path() the local variable @type should always be updated
after we hit any file/dir.

But if @filename is NULL from the very beginning, then we don't
initialize it and return it directly.

To prevent such problem from happening, we initialize @type to
BTRFS_FT_UNKNOWN.
For normal execution route, it will get updated for each filename we
resolved.
Buf if we didn't find any path, we check if the type is still FT_UNKNOWN
and ret == 0. If true we know there is something wrong, just return
-EUCLEAN to inform the caller.

Reported-by: Coverity CID 312958
Signed-off-by: Qu Wenruo 
Reviewed-by: Marek Behún

fs: btrfs: Cleanup the old implementation

2020-09-08T01:00:36+00:00

This cleans up the now unneeded code from the old btrfs implementation.

Signed-off-by: Qu Wenruo 
Reviewed-by: Marek Behún

fs: btrfs: Implement btrfs_file_read()

2020-09-08T01:00:36+00:00

This version of btrfs_file_read() has the following new features:
- Tries all mirrors
- More handling on unaligned size
- Better compressed extent handling
  The old implementation doesn't handle compressed extent with offset
  properly: we need to read out the whole compressed extent, then
  decompress the whole extent, and only then copy the requested part.

Signed-off-by: Qu Wenruo 
Reviewed-by: Marek Behún