On Fri, Jan 13, 2017 at 03:42:19AM +0000, Al Viro wrote: > On Thu, Jan 12, 2017 at 12:03:28PM -0500, Theodore Ts'o wrote: > > On Thu, Jan 12, 2017 at 04:00:16PM +0800, zhangyi (F) wrote: > > > > > > At the same time, I think other file systems may have the same problem, do > > > you think we should put these detections on the VFS layer? Thus other file > > > systems no need to do the same things, but the disadvantage is that we can > > > not call ext4_error to report ext4 inconsistency. > > > > There are file systems which don't have inodes per-se where the > > i_nlinks could be a something which is simulated by the file system. > > So it's not *necessarily* an on-disk inconsistency. > > > > We'll have to see if Al and other file system developers are > > agreeable, but one thing that we could do is to do the detection in > > the VFS layer (which it is actually easier to do), and if they find an > > issue, they can just pass a report via a callback function found in > > the struct_operations structure. If there isn't such a function > > defined, or the function returns 0, the VFS could just do nothing; if > > it returns an error code, then that would get reflected back up to > > userspace, plus whatever other action the file system sees fit to do. > > Detection of what? Zero ->i_nlink on inode of dentry that passes e.g. > may_delete()? Or other impossible cases where there is a valid dentry pointing at an inode with zero i_nlink. I am fairly sure this should **never** happen in the case of unlink(2), rmdir(2), or by the time we call file_ops->open(), and if it does, it indicates that the underlying on-disk file system (at least for ext4) is corrupt. Am I missing a case? And do you have an opinion about whether we should be trying to do this check at the VFS layer versus inside ext4? Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
