1. 24 Jun, 2010 3 commits
    • Dave Chinner's avatar
      xfs: remove block number from inode lookup code · 7b6259e7
      Dave Chinner authored
      The block number comes from bulkstat based inode lookups to shortcut
      the mapping calculations. We ar enot able to trust anything from
      bulkstat, so drop the block number as well so that the correct
      lookups and mappings are always done.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      7b6259e7
    • Dave Chinner's avatar
      xfs: rename XFS_IGET_BULKSTAT to XFS_IGET_UNTRUSTED · 1920779e
      Dave Chinner authored
      Inode numbers may come from somewhere external to the filesystem
      (e.g. file handles, bulkstat information) and so are inherently
      untrusted. Rename the flag we use for these lookups to make it
      obvious we are doing a lookup of an untrusted inode number and need
      to verify it completely before trying to read it from disk.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      1920779e
    • Dave Chinner's avatar
      xfs: validate untrusted inode numbers during lookup · 7124fe0a
      Dave Chinner authored
      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: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      7124fe0a
  2. 23 Jun, 2010 1 commit
  3. 24 Jun, 2010 1 commit
  4. 12 Jun, 2010 1 commit
  5. 11 Jun, 2010 34 commits