1. 08 Feb, 2008 13 commits
  2. 20 Dec, 2007 2 commits
    • Milan Broz's avatar
      dm crypt: use bio_add_page · 91e10625
      Milan Broz authored
      
      
      Fix possible max_phys_segments violation in cloned dm-crypt bio.
      
      In write operation dm-crypt needs to allocate new bio request
      and run crypto operation on this clone. Cloned request has always
      the same size, but number of physical segments can be increased
      and violate max_phys_segments restriction.
      
      This can lead to data corruption and serious hardware malfunction.
      This was observed when using XFS over dm-crypt and at least
      two HBA controller drivers (arcmsr, cciss) recently.
      
      Fix it by using bio_add_page() call (which tests for other
      restrictions too) instead of constructing own biovec.
      
      All versions of dm-crypt are affected by this bug.
      
      Cc: stable@kernel.org
      Cc:  dm-crypt@saout.de
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      91e10625
    • Milan Broz's avatar
      dm crypt: fix write endio · adfe4770
      Milan Broz authored
      
      
      Fix BIO_UPTODATE test for write io.
      
      Cc: stable@kernel.org
      Cc: dm-crypt@saout.de
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      adfe4770
  3. 27 Oct, 2007 1 commit
  4. 24 Oct, 2007 1 commit
  5. 22 Oct, 2007 1 commit
  6. 20 Oct, 2007 7 commits
  7. 19 Oct, 2007 1 commit
  8. 16 Oct, 2007 1 commit
    • Neil Brown's avatar
      Fix memory leak in dm-crypt · 644bd2f0
      Neil Brown authored
      
      
      dm-crypt used the ->bi_size member in the bio endio handling to
      free the appropriate pages, but it frees all of it from both call
      paths. With the ->bi_end_io() changes, ->bi_size was always 0 since
      we don't do partial completes. This caused dm-crypt to leak memory.
      
      Fix this by removing the size argument from crypt_free_buffer_pages().
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      644bd2f0
  9. 10 Oct, 2007 1 commit
  10. 22 Jul, 2007 1 commit
  11. 12 Jul, 2007 2 commits
  12. 09 May, 2007 6 commits
  13. 30 Apr, 2007 1 commit
    • Jens Axboe's avatar
      [BLOCK] Don't pin lots of memory in mempools · 5972511b
      Jens Axboe authored
      
      
      Currently we scale the mempool sizes depending on memory installed
      in the machine, except for the bio pool itself which sits at a fixed
      256 entry pre-allocation.
      
      There's really no point in "optimizing" this OOM path, we just need
      enough preallocated to make progress. A single unit is enough, lets
      scale it down to 2 just to be on the safe side.
      
      This patch saves ~150kb of pinned kernel memory on a 32-bit box.
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      5972511b
  14. 08 Dec, 2006 2 commits