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

fs: btrfs: Add missing cache aligned allocation

2021-05-26T21:26:07+00:00

The superblock buffer must be cache aligned, since it might be used
in DMA context, allocate it using ALLOC_CACHE_ALIGN_BUFFER() just
like it was done in btrfs_read_superblock() and read_tree_node().

This fixes this output on boot and non-working btrfs on iMX53:
CACHE: Misaligned operation at range [ced299d0, ced2a9d0]

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

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: do not fail when offset of a ROOT_ITEM is not -1

2021-03-01T14:53:46+00:00

When the btrfs_read_fs_root() function is searching a ROOT_ITEM with
location key offset other than -1, it currently fails via BUG_ON.

The offset can have other value than -1, though. This can happen for
example if a subvolume is renamed:

  $ btrfs subvolume create X && sync
  Create subvolume './X'
  $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: X$
        location key (270 ROOT_ITEM 18446744073709551615) type DIR
        transid 283 data_len 0 name_len 1
        name: X
  $ mv X Y && sync
  $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: Y$
        location key (270 ROOT_ITEM 0) type DIR
        transid 285 data_len 0 name_len 1
        name: Y

As can be seen the offset changed from -1ULL to 0.

Do not fail in this case.

Signed-off-by: Marek Behún 
Cc: David Sterba 
Cc: Qu Wenruo 
Cc: Tom Rini

fs: btrfs: change directory list output to be aligned as before

2021-02-24T21:51:48+00:00

Since commit 325dd1f642dd ("fs: btrfs: Use btrfs_iter_dir() to ...")
when btrfs is listing a directory, the output is not aligned:

           15  Wed Sep 09 13:20:03 2020  boot.scr -> @/boot/boot.scr
            0  Tue Feb 02 12:42:09 2021  @
          108  Tue Feb 02 12:54:04 2021  1.info

Return back to how it was displayed previously, i.e.:

           15  Wed Sep 09 13:20:03 2020  boot.scr -> @/boot/boot.scr
            0  Tue Feb 02 12:42:09 2021  @
  <   >        108  Tue Feb 02 12:54:04 2021  1.info

Instead of '', print '<   >', as ext4 driver.

If an unknown directory item type is encountered, we will print the type
number left padded with spaces, enclosed by '?', instead of '<' and '>',
i.e.:

  ? 30?        .............................  name

Signed-off-by: Marek Behún 
Fixes: 325dd1f642dd ("fs: btrfs: Use btrfs_iter_dir() to replace ...")
Cc: David Sterba 
Cc: Qu Wenruo 
Cc: Tom Rini 
Reviewed-by: Qu Wenruo

fs: btrfs: skip xattrs in directory listing

2021-02-24T21:51:48+00:00

Skip xattrs in directory listing. U-Boot filesystem drivers do not list
xattrs.

Signed-off-by: Marek Behún 
Cc: David Sterba 
Cc: Qu Wenruo 
Cc: Tom Rini 
Reviewed-by: Qu Wenruo

fs: btrfs: Select SHA256 in Kconfig

2021-01-29T15:36:49+00:00

Since commit 565a4147d17a ("fs: btrfs: Add more checksum algorithms")
btrfs uses the sha256 checksum algorithm. But Kconfig lacks to select
it. This leads to compilation errors:
fs/built-in.o: In function `hash_sha256':
fs/btrfs/crypto/hash.c:25: undefined reference to `sha256_starts'
fs/btrfs/crypto/hash.c:26: undefined reference to `sha256_update'
fs/btrfs/crypto/hash.c:27: undefined reference to `sha256_finish'

Signed-off-by: Matthias Brugger 
Reviewed-by: Qu Wenruo

fs: btrfs: simplify close_ctree_fs_info()

2021-01-20T19:01:45+00:00

At the beginning of close_ctree_fs_info() the value 0 is assigned to err
and never changed before testing it.

Let's get rid of the superfluous variable.

Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs")
Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Qu Wenruo

fs: btrfs: volumes: prevent overflow for multiplying

2021-01-20T19:01:08+00:00

In __btrfs_map_block() we do a int * int and assign it to u64.
This is not safe as the result (int * int) is still evaluated as (int)
thus it can overflow.

Convert one of the multiplier to u64 to prevent such problem.

In real world, this should not cause problem as we have device number
limit thus it won't go beyond 4G for a single stripe.

But it's harder to teach coverity about all these hidden limits, so just
fix the possible overflow.

Reported-by: Coverity CID 312957
Reported-by: Coverity CID 312948
Signed-off-by: Qu Wenruo

fs: btrfs: initialize @ret to 0 to prevent uninitialized return value

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

In show_dir() if we hit a ROOT_ITEM, we can exit with uninitialized
@ret.

Fix it by initializing it to 0.

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

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