bcm63xx/u-boot/fs/btrfs, branch master

fs: btrfs: add zstd decompression support

2019-05-05T12:48:50Z

This adds decompression support for Zstandard, which has been included in Linux btrfs driver for some time. Signed-off-by: Marek Behún

fs: btrfs: fix btrfs methods return values on failure

2019-05-03T11:30:31Z

The btrfs implementation methods .ls(), .size() and .read() returns 1 on failure, but the command handlers expect values <0 on failure. For example if given a nonexistent path, the load command currently returns success, and hush scripting does not work. Fix this by setting return values of these methods to -1 instead of 1 on failure. Signed-off-by: Marek Behún

fs: btrfs: Do not print mount fail message when not btrfs filesystem

2019-05-03T11:23:17Z

Other filesystem drivers don't do this. Signed-off-by: Marek Behún

Revert "fs: btrfs: fix false negatives in ROOT_ITEM search"

2019-04-27T15:35:44Z

Per Pierre this change shouldn't have been applied as it was superseded by "fs: btrfs: fix btrfs_search_tree invalid results" which is also applied now as 1627e5e5985d. This reverts commit 633967f9818cb6a0e87ffa8cba33148a5bcc6edb. Signed-off-by: Tom Rini

fs: btrfs: fix btrfs_search_tree invalid results

2019-04-26T21:53:16Z

btrfs_search_tree should return the first item in the tree that is greater or equal to the searched item. The search algorithm did not properly handle the edge case where the searched item is higher than the last item of the node but lower than the first item of the next node. Instead of properly returning the first item of the next node, it was returning an invalid path pointer (pointing to a non-existent item after the last item of the node + 1). This fixes two issues in the btrfs driver: - Looking for a ROOT_ITEM could fail if it was the first item of its leaf node. - Iterating through DIR_INDEX entries (for readdir) could fail if the first DIR_INDEX entry was the first item of a leaf node. Signed-off-by: Pierre Bourdon Cc: Marek Behun

fs: btrfs: fix false negatives in ROOT_ITEM search

2019-04-26T21:53:15Z

ROOT_ITEMs in btrfs are referenced without knowing their actual "offset" value. To perform these searches using only two items from the key, the btrfs driver uses a special "btrfs_search_tree_key_type" function. The algorithm used by that function to transform a 3-tuple search into a 2-tuple search was subtly broken, leading to items not being found if they were the first in their tree node. This commit fixes btrfs_search_tree_key_type to properly behave in these situations. Signed-off-by: Pierre Bourdon Cc: Marek Behun

fs: btrfs: Fix tree traversal with btrfs_next_slot()

2018-10-08T18:45:02Z

When traversing slots in a btree (via btrfs_path) with btrfs_next_slot(), we didn't correctly identify that the last slot in the leaf was reached and we should jump to the next leaf. This could lead to any kind of runtime errors or corruptions, like: * file data not being read at all, or is read partially * file is read but is corrupted * (any) metadata being corrupted or not read at all, etc The easiest way to reproduce this is to read a large enough file that its EXTENT_DATA items don't fit into a single leaf. Signed-off-by: Yevgeny Popovych Cc: Marek Behun Tested-by: Marek Behún

fs: btrfs: Fix cache alignment bugs

2018-09-30T17:00:37Z

The btrfs implementation passes cache-unaligned buffers into the block layer, which triggers cache alignment problems down in the block device drivers. Align the buffers to prevent this. Signed-off-by: Marek Vasut Cc: Marek Behun

fs: btrfs: Fix wrong comparison in logical to physical mapping

2018-07-20T19:37:44Z

The comparison logical > item->logical + item->length in btrfs_map_logical_to_physical is wrong and should be instead logical >= item->logical + item->length For example, if item->logical = 4096 item->length = 4096 and we are looking for logical = 8192, it is not part of item (item is [4096, 8191]). But the comparison is false and we think we have found the correct item, although we should be searing in the right subtree. This fixes some bugs I encountered. Signed-off-by: Marek Behun

fs: btrfs: Do not fail when all root_backups are empty

2018-06-18T18:43:12Z

This is the case when reading freshly created filesystem. The error message is like the following: btrfs_read_superblock: No valid root_backup found! Since the data from super_roots/root_backups is not actually used - decided to rework btrfs_newest_root_backup() into btrfs_check_super_roots() that will only check if super_roots array is valid and correctly handle empty scenario. As a result: * btrfs_read_superblock() now only checks if super_roots array is valid; the case when it is empty is considered OK. * removed root_backup pointer from btrfs_info, which would be NULL in case of empty super_roots. * btrfs_read_superblock() verifies number of devices from the superblock itself, not newest root_backup. Signed-off-by: Yevgeny Popovych Cc: Marek Behun Cc: Sergey Struzh