1. 14 10月, 2010 7 次提交
    • C
      hfsplus: create correct initial catalog entries for device files · 90e61690
      Christoph Hellwig 提交于
      Make sure the initial insertation of the catalog entry already contains
      the device number by calling init_special_inode early and setting writing
      out the dev field of the on-disk permission structure.  The latter is
      facilitated by sharing the almost identical hfsplus_set_perms helpers
      between initial catalog entry creating and ->write_inode.
      
      Unless we crashed just after mknod this bug was harmless as the inode
      is marked dirty at the end of hfsplus_mknod, and hfsplus_write_inode
      will update the catalog entry to contain the correct value.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      90e61690
    • C
      hfsplus: remove superflous rootflags field in hfsplus_inode_info · 722c55d1
      Christoph Hellwig 提交于
      The rootflags field in hfsplus_inode_info only caches the immutable and
      append-only flags in the VFS inode, so we can easily get rid of it.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      722c55d1
    • C
      hfsplus: fix link corruption · f6089ff8
      Christoph Hellwig 提交于
      HFS implements hardlink by using indirect catalog entries that refer to a hidden
      directly.  The link target is cached in the dev field in the HFS+ specific
      inode, which is also used for the device number for device files, and inside
      for passing the nlink value of the indirect node from hfsplus_cat_write_inode
      to a helper function.  Now if we happen to write out the indirect node while
      hfsplus_link is creating the catalog entry we'll get a link pointing to the
      linkid of the current nlink value.  This can easily be reproduced by a large
      enough loop of local git-clone operations.
      
      Stop abusing the dev field in the HFS+ inode for short term storage by
      refactoring the way the permission structure in the catalog entry is
      set up, and rename the dev field to linkid to avoid any confusion.
      
      While we're at it also prevent creating hard links to special files, as
      the HFS+ dev and linkid share the same space in the on-disk structure.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      f6089ff8
    • C
      hfsplus: validate btree flags · 13571a69
      Christoph Hellwig 提交于
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      13571a69
    • E
      hfsplus: handle more on-disk corruptions without oopsing · 9250f925
      Eric Sandeen 提交于
      hfs seems prone to bad things when it encounters on disk corruption.  Many
      values are read from disk, and used as lengths to memcpy, as an example.
      This patch fixes up several of these problematic cases.
      
      o sanity check the on-disk maximum key lengths on mount
        (these are set to a defined value at mkfs time and shouldn't differ)
      o check on-disk node keylens against the maximum key length for each tree
      o fix hfs_btree_open so that going out via free_tree: doesn't wind
        up in hfs_releasepage, which wants to follow the very pointer
        we were trying to set up:
      	HFS_SB(sb)->cat_tree = hfs_btree_open()
          .
        failure gets to hfs_releasepage and tries to follow HFS_SB(sb)->cat_tree
      
      Tested with the fsfuzzer; it survives more than it used to.
      
      [hch: ported of commit cf059462 from hfs]
      [hch: added the fixes from 5581d018ed3493d226e7a4d645d9c8a5af6c36b]
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      9250f925
    • A
      hfsplus: hfs_bnode_find() can fail, resulting in hfs_bnode_split() breakage · b6b41424
      Al Viro 提交于
      oops and fs corruption; the latter can happen even on valid fs in case of oom.
      
      [hch: port of commit 3d10a15d from hfs]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      b6b41424
    • J
      hfsplus: fix oops on mount with corrupted btree extent records · ee527162
      Jeff Mahoney 提交于
      A particular fsfuzzer run caused an hfs file system to crash on mount. This
      is due to a corrupted MDB extent record causing a miscalculation of
      HFSPLUS_I(inode)->first_blocks for the extent tree. If the extent records
      are zereod out, then it won't trigger the first_blocks special case and
      instead falls through to the extent code, which we're in the middle
      of initializing.
      
      This patch catches the 0 size extent records, reports the corruption,
      and fails the mount.
      
      [hch: ported of commit 47f365eb from hfs]
      Reported-by: NRamon de Carvalho Valle <rcvalle@linux.vnet.ibm.com>
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      ee527162
  2. 01 10月, 2010 20 次提交
  3. 29 9月, 2010 6 次提交
  4. 28 9月, 2010 7 次提交