On 2020/11/11 下午9:38, Pavel Machek wrote:
> Hi!
>
>>>> From: Qu Wenruo <wqu@xxxxxxxx>
>>>>
>>>> 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;
>>>> + }
>
