1. 06 12月, 2007 1 次提交
    • J
      jbd: Fix assertion failure in fs/jbd/checkpoint.c · d4beaf4a
      Jan Kara 提交于
      Before we start committing a transaction, we call
      __journal_clean_checkpoint_list() to cleanup transaction's written-back
      buffers.
      
      If this call happens to remove all of them (and there were already some
      buffers), __journal_remove_checkpoint() will decide to free the transaction
      because it isn't (yet) a committing transaction and soon we fail some
      assertion - the transaction really isn't ready to be freed :).
      
      We change the check in __journal_remove_checkpoint() to free only a
      transaction in T_FINISHED state.  The locking there is subtle though (as
      everywhere in JBD ;().  We use j_list_lock to protect the check and a
      subsequent call to __journal_drop_transaction() and do the same in the end
      of journal_commit_transaction() which is the only place where a transaction
      can get to T_FINISHED state.
      
      Probably I'm too paranoid here and such locking is not really necessary -
      checkpoint lists are processed only from log_do_checkpoint() where a
      transaction must be already committed to be processed or from
      __journal_clean_checkpoint_list() where kjournald itself calls it and thus
      transaction cannot change state either.  Better be safe if something
      changes in future...
      Signed-off-by: NJan Kara <jack@suse.cz>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d4beaf4a
  2. 20 10月, 2007 1 次提交
  3. 18 10月, 2007 1 次提交
  4. 17 7月, 2007 1 次提交
  5. 09 5月, 2007 1 次提交
  6. 23 12月, 2006 1 次提交
  7. 04 10月, 2006 1 次提交
  8. 26 9月, 2006 1 次提交
    • J
      [PATCH] jbd: fix commit of ordered data buffers · 3998b930
      Jan Kara 提交于
      Original commit code assumes, that when a buffer on BJ_SyncData list is
      locked, it is being written to disk.  But this is not true and hence it can
      lead to a potential data loss on crash.  Also the code didn't count with
      the fact that journal_dirty_data() can steal buffers from committing
      transaction and hence could write buffers that no longer belong to the
      committing transaction.  Finally it could possibly happen that we tried
      writing out one buffer several times.
      
      The patch below tries to solve these problems by a complete rewrite of the
      data commit code.  We go through buffers on t_sync_datalist, lock buffers
      needing write out and store them in an array.  Buffers are also immediately
      refiled to BJ_Locked list or unfiled (if the write out is completed).  When
      the array is full or we have to block on buffer lock, we submit all
      accumulated buffers for IO.
      
      [suitable for 2.6.18.x around the 2.6.19-rc2 timeframe]
      Signed-off-by: NJan Kara <jack@suse.cz>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3998b930
  9. 28 8月, 2006 1 次提交
  10. 23 6月, 2006 1 次提交
    • J
      [PATCH] jbd: fix BUG in journal_commit_transaction() · 9ada7340
      Jan Kara 提交于
      Fix possible assertion failure in journal_commit_transaction() on
      jh->b_next_transaction == NULL (when we are processing BJ_Forget list and
      buffer is not jbddirty).
      
      !jbddirty buffers can be placed on BJ_Forget list for example by
      journal_forget() or by __dispose_buffer() - generally such buffer means
      that it has been freed by this transaction.
      
      Freed buffers should not be reallocated until the transaction has committed
      (that's why we have the assertion there) but they *can* be reallocated when
      the transaction has already been committed to disk and we are just
      processing the BJ_Forget list (as soon as we remove b_committed_data from
      the bitmap bh, ext3 will be able to reallocate buffers freed by the
      committing transaction).  So we have to also count with the case that the
      buffer has been reallocated and b_next_transaction has been already set.
      
      And one more subtle point: it can happen that we manage to reallocate the
      buffer and also mark it jbddirty.  Then we also add the freed buffer to the
      checkpoint list of the committing trasaction.  But that should do no harm.
      
      Non-jbddirty buffers should be filed to BJ_Reserved and not BJ_Metadata
      list.  It can actually happen that we refile such buffers during the commit
      phase when we reallocate in the running transaction blocks deleted in
      committing transaction (and that can happen if the committing transaction
      already wrote all the data and is just cleaning up BJ_Forget list).
      Signed-off-by: NJan Kara <jack@suse.cz>
      Acked-by: N"Stephen C. Tweedie" <sct@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9ada7340
  11. 15 2月, 2006 1 次提交
  12. 19 1月, 2006 1 次提交
  13. 07 11月, 2005 1 次提交
  14. 08 9月, 2005 2 次提交
  15. 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