1. 17 12月, 2010 1 次提交
  2. 14 10月, 2010 1 次提交
    • 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
  3. 01 10月, 2010 1 次提交
  4. 19 1月, 2006 1 次提交
  5. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4