• D
    xfs: validate untrusted inode numbers during lookup · 7124fe0a
    Dave Chinner 提交于
    When we decode a handle or do a bulkstat lookup, we are using an
    inode number we cannot trust to be valid. If we are deleting inode
    chunks from disk (default noikeep mode), then we cannot trust the on
    disk inode buffer for any given inode number to correctly reflect
    whether the inode has been unlinked as the di_mode nor the
    generation number may have been updated on disk.
    
    This is due to the fact that when we delete an inode chunk, we do
    not write the clusters back to disk when they are removed - instead
    we mark them stale to avoid them being written back potentially over
    the top of something that has been subsequently allocated at that
    location. The result is that we can have locations of disk that look
    like they contain valid inodes but in reality do not. Hence we
    cannot simply convert the inode number to a block number and read
    the location from disk to determine if the inode is valid or not.
    
    As a result, and XFS_IGET_BULKSTAT lookup needs to actually look the
    inode up in the inode allocation btree to determine if the inode
    number is valid or not.
    
    It should be noted even on ikeep filesystems, there is the
    possibility that blocks on disk may look like valid inode clusters.
    e.g. if there are filesystem images hosted on the filesystem. Hence
    even for ikeep filesystems we really need to validate that the inode
    number is valid before issuing the inode buffer read.
    Signed-off-by: NDave Chinner <dchinner@redhat.com>
    Reviewed-by: NChristoph Hellwig <hch@lst.de>
    7124fe0a
xfs_ialloc.c 43.3 KB