An error occurred fetching the project authors.
  1. 23 Feb, 2016 1 commit
  2. 17 Oct, 2015 1 commit
  3. 15 Jun, 2015 1 commit
    • Michal Hocko's avatar
      jbd2: get rid of open coded allocation retry loop · 7b506b10
      Michal Hocko authored
      insert_revoke_hash does an open coded endless allocation loop if
      journal_oom_retry is true. It doesn't implement any allocation fallback
      strategy between the retries, though. The memory allocator doesn't know
      about the never fail requirement so it cannot potentially help to move
      on with the allocation (e.g. use memory reserves).
      
      Get rid of the retry loop and use __GFP_NOFAIL instead. We will lose the
      debugging message but I am not sure it is anyhow helpful.
      
      Do the same for journal_alloc_journal_head which is doing a similar
      thing.
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      7b506b10
  4. 14 May, 2015 1 commit
    • Darrick J. Wong's avatar
      jbd2: fix r_count overflows leading to buffer overflow in journal recovery · e531d0bc
      Darrick J. Wong authored
      The journal revoke block recovery code does not check r_count for
      sanity, which means that an evil value of r_count could result in
      the kernel reading off the end of the revoke table and into whatever
      garbage lies beyond.  This could crash the kernel, so fix that.
      
      However, in testing this fix, I discovered that the code to write
      out the revoke tables also was not correctly checking to see if the
      block was full -- the current offset check is fine so long as the
      revoke table space size is a multiple of the record size, but this
      is not true when either journal_csum_v[23] are set.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Cc: stable@vger.kernel.org
      e531d0bc
  5. 30 Oct, 2014 1 commit
  6. 29 Aug, 2014 1 commit
    • Darrick J. Wong's avatar
      jbd2: fix descriptor block size handling errors with journal_csum · db9ee220
      Darrick J. Wong authored
      It turns out that there are some serious problems with the on-disk
      format of journal checksum v2.  The foremost is that the function to
      calculate descriptor tag size returns sizes that are too big.  This
      causes alignment issues on some architectures and is compounded by the
      fact that some parts of jbd2 use the structure size (incorrectly) to
      determine the presence of a 64bit journal instead of checking the
      feature flags.
      
      Therefore, introduce journal checksum v3, which enlarges the
      descriptor block tag format to allow for full 32-bit checksums of
      journal blocks, fix the journal tag function to return the correct
      sizes, and fix the jbd2 recovery code to use feature flags to
      determine 64bitness.
      
      Add a few function helpers so we don't have to open-code quite so
      many pieces.
      
      Switching to a 16-byte block size was found to increase journal size
      overhead by a maximum of 0.1%, to convert a 32-bit journal with no
      checksumming to a 32-bit journal with checksum v3 enabled.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reported-by: default avatarTR Reardon <thomas_reardon@hotmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      db9ee220
  7. 04 Jun, 2013 1 commit
  8. 27 May, 2012 1 commit
  9. 20 Feb, 2012 1 commit
  10. 28 Dec, 2011 1 commit
    • Yongqiang Yang's avatar
      jbd2: clear revoked flag on buffers before a new transaction started · 1ba37268
      Yongqiang Yang authored
      Currently, we clear revoked flag only when a block is reused.  However,
      this can tigger a false journal error.  Consider a situation when a block
      is used as a meta block and is deleted(revoked) in ordered mode, then the
      block is allocated as a data block to a file.  At this moment, user changes
      the file's journal mode from ordered to journaled and truncates the file.
      The block will be considered re-revoked by journal because it has revoked
      flag still pending from the last transaction and an assertion triggers.
      
      We fix the problem by keeping the revoked status more uptodate - we clear
      revoked flag when switching revoke tables to reflect there is no revoked
      buffers in current transaction any more.
      Signed-off-by: default avatarYongqiang Yang <xiaoqiangnk@gmail.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      1ba37268
  11. 31 Mar, 2011 1 commit
  12. 18 Aug, 2010 1 commit
    • Christoph Hellwig's avatar
      remove SWRITE* I/O types · 9cb569d6
      Christoph Hellwig authored
      These flags aren't real I/O types, but tell ll_rw_block to always
      lock the buffer instead of giving up on a failed trylock.
      
      Instead add a new write_dirty_buffer helper that implements this semantic
      and use it from the existing SWRITE* callers.  Note that the ll_rw_block
      code had a bug where it didn't promote WRITE_SYNC_PLUG properly, which
      this patch fixes.
      
      In the ufs code clean up the helper that used to call ll_rw_block
      to mirror sync_dirty_buffer, which is the function it implements for
      compound buffers.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      9cb569d6
  13. 14 Apr, 2009 1 commit
  14. 27 Mar, 2009 1 commit
  15. 17 Apr, 2008 2 commits
  16. 28 Apr, 2008 1 commit
  17. 30 Mar, 2008 1 commit
  18. 29 Jan, 2008 1 commit
  19. 17 Oct, 2007 1 commit
  20. 20 Jul, 2007 1 commit
    • Paul Mundt's avatar
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt authored
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      20c2df83
  21. 16 Jul, 2007 1 commit
  22. 09 May, 2007 1 commit
  23. 08 May, 2007 1 commit
  24. 07 Dec, 2006 1 commit
  25. 11 Oct, 2006 6 commits
  26. 27 Sep, 2006 1 commit
  27. 07 Sep, 2005 2 commits
  28. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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