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 <wqu@xxxxxxxx> >>> Reviewed-by: Nikolay Borisov <nborisov@xxxxxxxx> >> >> 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. >
