The test case fsck-tests/015-check-bad-memory-access can't be repair by
btrfs check, and it's a fortunate bug makes original mode to forget the
error code from extent tree, making original mode pass it.
So fuzz-tests is more suitable for it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If first inode item is missing, lowmem check will detect it but does not
output any error message.
Add error message for it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Old lowmem check doesn't check if the inline extent is compressed and
always checks extent numbytes against inline item size.
And when it finds the extent numbytes mismatch with inline item size it
doesn't output any error message, just return error silently, making it
quite hard to debug.
Fix it by only checking extent numbytes against inline item size when
the extent is not compressed, and output error message.
Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If one extent item has no inline ref, btrfs lowmem mode check can give
false alert without outputting any error message.
The problem is lowmem mode always assumes that extent item has inline
refs, and when it encounters such case it flags the extent item has
wrong size, but doesn't output the error message.
Although we already have such image submitted, at the commit time due to
another bug in cmds-check return value, it doesn't detect it until that
bug is fixed.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Btrfs lowmem check can report false csum error like:
ERROR: root 5 EXTENT_DATA[257 0] datasum missing
ERROR: root 5 EXTENT_DATA[257 4096] prealloc shouldn't have datasum
This is because lowmem check code always compare the found csum size
with the whole extent which data extents points to.
Normally it's OK, but when prealloc extent is written, or reflink is
done, data extent can points to part of a larger extent, making the csum
check wrong.
To fix it, the csum check part is modified to handle plain and
compressed extents in different ways:
1) Plain extent
Only search csums for the range it refers to.
So the search range is from (disk_bytenr + extent_offset) and search
length is (extent_num_bytes)
2) Compressed extent
Search the whole extent.
Search range is from (disk_bytner) and search length is
(disk_num_bytes)
Reported-by: Chris Murphy <chris@colorremedies.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Although we output error like "errors found in extent allocation tree or
chunk allocation", but we lacks such output for other trees, but leaving
the final "found error is %d" to catch the last return value(and
sometime it's cleared)
This patch adds extra error message for top level error path, and modify
the last "found error is %d" to "error(s) found" or "no error found".
Cc: Christoph Anton Mitterer <calestyo@scientia.net>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Since btrfs_search_slot() can point to the slot which is beyond the
leaves' capacity, we should pay extra attention when doing afterward
search.
While for lowmem check, several places uses afterward search:
1) Block group item used space check
2) Device item used space check
3) Data extent backref check.
In the following case for block group item check, btrfs lowmem mode
check will skip the block group and report false alert:
leaf 29405184 items 37 free space 1273 generation 11 owner 2
...
item 36 key (77594624 EXTENT_ITEM 2097152)
extent refs 1 gen 8 flags DATA
extent data backref root 5 objectid 265 offset 0 count 1
leaf 29409280 items 43 free space 670 generation 11 owner 2
item 0 key (96468992 EXTENT_ITEM 2097152)
extent refs 1 gen 8 flags DATA
extent data backref root 5 objectid 274 offset 0 count 1
item 1 key (96468992 BLOCK_GROUP_ITEM 33554432)
block group used 2265088 chunk_objectid 256 flags DATA
When checking block group item, we will search key (96468992 0 0) to
start from the first item in the block group.
While search_slot() will point to leaf 29405184, slot 37 which is beyond
leaf capacity.
And when reading key from slot 37, uninitialized data can be read out
and cause us to exit block group item check, leading to false alert.
Fix it by checking path.slot[0] before reading out the key.
Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
Reported-by: Chris Murphy <chris@colorremedies.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The symbol __error was undefined and the rule did not use the
dependencies from the rule definiton, like the rest.
Signed-off-by: David Sterba <dsterba@suse.com>
