On 2019/3/27 上午12:02, David Sterba wrote:
> On Mon, Mar 25, 2019 at 12:27:24PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/3/20 下午2:37, Qu Wenruo wrote:
>>> 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:
>>> - inode key objectid
>>> Should be ROOT_DIR_DIR or [256, (u64)-256] or FREE_INO.
>>>
>>> - inode key offset
>>> Should be 0
>>>
>>> - inode item generation
>>> - inode item transid
>>> No newer than sb generation + 1.
>>> The +1 is for log tree.
>>>
>>> - inode item mode
>>> No unknown bits.
>>> No invalid S_IF* bit.
>>> NOTE: S_IFMT check is not enough, need to check every know type.
>>>
>>> - inode item nlink
>>> Dir should have no more link than 1.
>>>
>>> - inode item flags
>>>
>>> Signed-off-by: Qu Wenruo <w...@suse.com>
>>> Reviewed-by: Nikolay Borisov <nbori...@suse.com>
>>
>> There is some bug report of kernel producing free space cache inode with
>> mode 0, which is invalid and can be detected by this patch.
>>
>> Although the patch itself is good, I'm afraid we need to address the
>> invalid inode mode created by old kernel in btrfs-progs at least before
>> merging this patch into upstream.
>
> Can this be addressed on the kernel side? Like detecting the invalid
> mode, print a warning and the fix on the next write. The progs can
> detect and fix that too of course.
So far even on older fs images (like those in btrfs-progs fsck tests), I
noticed no such invalid free space inode at all.
And from the history of that code, the mode is fixed to 100600 since 2010.
Currently I believe it's uncommon to see that case.
Furthermore, the btrfs-progs fix for such case is already submitted, as
long as we have a minor release to include that fix, it should be OK.
>
> So I'll keep the patch working as-is, we can relax the error to a
> warning if we're out of time or find out that it needs to be that way
> due to backward compatibilit reasons.
>
