On 2020/11/11 下午9:38, Pavel Machek wrote:
Hi!
From: Qu Wenruo wqu@suse.com
commit 496245cac57e26d8b738d85c7a29cf9a47610f3f upstream.
There is a report in kernel bugzilla about mismatch file type in dir item and inode item.
This inspires us to check inode mode in inode item.
This patch will check the following members:
- /* Here we use super block generation + 1 to handle log tree */
- if (btrfs_inode_generation(leaf, iitem) > super_gen + 1) {
inode_item_err(fs_info, leaf, slot,
"invalid inode generation: has %llu expect (0, %llu]",
btrfs_inode_generation(leaf, iitem),
super_gen + 1);
return -EUCLEAN;
- }
Printk suggests btrfs_inode_generation() may not be zero, but the condition does not actually check that. Should that be added?
Sorry, btrfs_inode_generation() here is exactly what we're checking here, so what's wrong?
Quoted message says "(0, ...]", while message below says "[0, ...]". I assume that means that btrfs_inode_generation() may not be zero in the first case, but may be zero in the second case. But the code does not test for zero here.
Zero for inode generation is more or less in the grey zone.
For inodes which can be accessed by users, inode 0 may cause small problems for send, but despite that, no obvious problem.
For btrfs internal generations, it can be 0 and cause nothing wrong.
So here we don't check inode_generation == 0 case at all, or we could lead to too many false alerts for older btrfs.
Thanks, Q
Best regards, Pavel
- /* Note for ROOT_TREE_DIR_ITEM, mkfs could set its transid 0 */
- if (btrfs_inode_transid(leaf, iitem) > super_gen + 1) {
inode_item_err(fs_info, leaf, slot,
"invalid inode generation: has %llu expect [0, %llu]",
btrfs_inode_transid(leaf, iitem), super_gen + 1);
return -EUCLEAN;
- }