On 2018年04月02日 18:47, Qu Wenruo wrote: > > > On 2018年03月28日 23:49, David Sterba wrote: >> On Tue, Mar 27, 2018 at 08:44:19PM +0800, Qu Wenruo wrote: >>> We have several reports about node pointer points to incorrect child >>> tree blocks, which could have even wrong owner and level but still with >>> valid generation and checksum. >>> >>> Although btrfs check could handle it and print error message like: >>> leaf parent key incorrect 60670574592 >>> >>> Kernel doesn't have enough check on this type of corruption correctly. >>> At least add such check to read_tree_block() and btrfs_read_buffer(), >>> where we need two new parameters @level and @first_key to verify the >>> child tree block. >>> >>> The new @level check is mandatory and all call sites are already >>> modified to extract expected level from its call chain. >>> >>> While @first_key is optional, the following call sites are skipping such >>> check: >>> 1) Root node/leaf >>> As ROOT_ITEM doesn't contain the first key, skip @first_key check. >>> 2) Direct backref >>> Only parent bytenr and level is known and we need to resolve the key >>> all by ourselves, skip @first_key check. >>> >>> Another note of this verification is, it needs extra info from nodeptr >>> or ROOT_ITEM, so it can't fit into current tree-checker framework, which >>> is limited to node/leaf boundary. >>> >>> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> >>> --- >>> changelog: >>> v2: >>> Make @level check mandatory, suggesed by Jeff and Nikolay. >>> Change parameter order as @level is now mandatory, put it in front of >>> @first_key. >>> Change verify_parent_level() to verify_key_level() to avoid confusion >>> on the @level parameter. >>> Add btrfs_error() output for CONFIG_BTRFS_DEBUG to help debugging. >> >> That's much better overall, thanks. Adding it to next. > > Nikolay reported a case where @first_key check seems to cause false alert. > (Although my xfstests check hasn't exposed it yet) > > Please discard this patch since it has the possibility to cause false > alert for btrfs core functionality. It turns out to be a racing related case in btree operations like push_leaf_right(). So it indeed brings some clue here. (Although still pretty hard to reproduce) Thanks, Qu > > Thanks, > Qu > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
Attachment:
signature.asc
Description: OpenPGP digital signature
