1. 07 11月, 2005 2 次提交
  2. 01 11月, 2005 1 次提交
    • A
      [PATCH] fix __writeback_single_inode WARN_ON · 659603ef
      Andrea Arcangeli 提交于
      When the inode count is zero in inode writeback, the
      
      	WARN_ON(!(inode->i_state & I_WILL_FREE));
      
      is broken, and needs to test for either I_WILL_FREE|I_FREEING.
      
      When the inode is in I_FREEING state, it's already out of the visibility
      of the vm so it can't be freed so it doesn't require the __iget and the
      generic_delete_inode path can call the sync internally to the lowlevel
      fs callback during the last iput. So the inode being in I_FREEING is
      also a valid condition for calling the sync with i_count == 0.
      
      The specific stack trace is this:
      
        0xc00000007b8fb6e0  0xc00000000010118c  .__writeback_single_inode +0x5c
        0xc00000007b8fb6e0  0xc0000000001014dc (lr) .sync_inode +0x3c
        0xc00000007b8fb790  0xc0000000001014dc  .sync_inode +0x3c
        0xc00000007b8fb820  0xc0000000001a5020  .ext2_sync_inode +0x64
        0xc00000007b8fb8f0  0xc0000000001a65b4  .ext2_truncate +0x3f8
        0xc00000007b8fba40  0xc0000000001a6940  .ext2_delete_inode +0xdc
        0xc00000007b8fbac0  0xc0000000000f7a5c  .generic_delete_inode +0x124
        0xc00000007b8fbb50  0xc0000000000f5fe0  .iput +0xb8
        0xc00000007b8fbbe0  0xc0000000000e9fd4  .sys_unlink +0x2a8
        0xc00000007b8fbd10  0xc00000000001048c  .ret_from_syscall_1 +0x0
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      659603ef
  3. 31 10月, 2005 1 次提交
    • A
      [PATCH] fix nr_unused accounting, and avoid recursing in iput with I_WILL_FREE set · 7f04c26d
      Andrea Arcangeli 提交于
       			list_move(&inode->i_list, &inode_in_use);
       		} else {
       			list_move(&inode->i_list, &inode_unused);
      +			inodes_stat.nr_unused++;
       		}
       	}
       	wake_up_inode(inode);
      
      Are you sure the above diff is correct? It was added somewhere between
      2.6.5 and 2.6.8. I think it's wrong.
      
      The only way I can imagine the i_count to be zero in the above path, is
      that I_WILL_FREE is set.  And if I_WILL_FREE is set, then we must not
      increase nr_unused.  So I believe the above change is buggy and it will
      definitely overstate the number of unused inodes and it should be backed
      out.
      
      Note that __writeback_single_inode before calling __sync_single_inode, can
      drop the spinlock and we can have both the dirty and locked bitflags clear
      here:
      
      		spin_unlock(&inode_lock);
      		__wait_on_inode(inode);
      		iput(inode);
      XXXXXXX
      		spin_lock(&inode_lock);
      	}
      	use inode again here
      
      a construct like the above makes zero sense from a reference counting
      standpoint.
      
      Either we don't ever use the inode again after the iput, or the
      inode_lock should be taken _before_ executing the iput (i.e. a __iput
      would be required). Taking the inode_lock after iput means the iget was
      useless if we keep using the inode after the iput.
      
      So the only chance the 2.6 was safe to call __writeback_single_inode
      with the i_count == 0, is that I_WILL_FREE is set (I_WILL_FREE will
      prevent the VM to free the inode in XXXXX).
      
      Potentially calling the above iput with I_WILL_FREE was also wrong
      because it would recurse in iput_final (the second mainline bug).
      
      The below (untested) patch fixes the nr_unused accounting, avoids recursing
      in iput when I_WILL_FREE is set and makes sure (with the BUG_ON) that we
      don't corrupt memory and that all holders that don't set I_WILL_FREE, keeps
      a reference on the inode!
      Signed-off-by: NAndrea Arcangeli <andrea@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7f04c26d
  4. 24 6月, 2005 1 次提交
  5. 01 5月, 2005 1 次提交
  6. 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
反馈
建议
客服 返回
顶部