1. 22 6月, 2009 2 次提交
  2. 03 4月, 2009 1 次提交
    • M
      dm io: make sync_io uninterruptible · b64b6bf4
      Mikulas Patocka 提交于
      If someone sends signal to a process performing synchronous dm-io call,
      the kernel may crash.
      
      The function sync_io attempts to exit with -EINTR if it has pending signal,
      however the structure "io" is allocated on stack, so already submitted io
      requests end up touching unallocated stack space and corrupting kernel memory.
      
      sync_io sets its state to TASK_UNINTERRUPTIBLE, so the signal can't break out
      of io_schedule() --- however, if the signal was pending before sync_io entered
      while (1) loop, the corruption of kernel memory will happen.
      
      There is no way to cancel in-progress IOs, so the best solution is to ignore
      signals at this point.
      
      Cc: stable@kernel.org
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      b64b6bf4
  3. 17 3月, 2009 1 次提交
  4. 18 2月, 2009 1 次提交
  5. 29 12月, 2008 1 次提交
    • J
      bio: allow individual slabs in the bio_set · bb799ca0
      Jens Axboe 提交于
      Instead of having a global bio slab cache, add a reference to one
      in each bio_set that is created. This allows for personalized slabs
      in each bio_set, so that they can have bios of different sizes.
      
      This means we can personalize the bios we return. File systems may
      want to embed the bio inside another structure, to avoid allocation
      more items (and stuffing them in ->bi_private) after the get a bio.
      Or we may want to embed a number of bio_vecs directly at the end
      of a bio, to avoid doing two allocations to return a bio. This is now
      possible.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      bb799ca0
  6. 22 10月, 2008 1 次提交
  7. 25 4月, 2008 4 次提交
    • M
      dm: unplug queues in threads · 7ff14a36
      Mikulas Patocka 提交于
      Remove an avoidable 3ms delay on some dm-raid1 and kcopyd I/O.
      
      It is specified that any submitted bio without BIO_RW_SYNC flag may plug the
      queue (i.e. block the requests from being dispatched to the physical device).
      
      The queue is unplugged when the caller calls blk_unplug() function. Usually, the
      sequence is that someone calls submit_bh to submit IO on a buffer. The IO plugs
      the queue and waits (to be possibly joined with other adjacent bios). Then, when
      the caller calls wait_on_buffer(), it unplugs the queue and submits the IOs to
      the disk.
      
      This was happenning:
      
      When doing O_SYNC writes, function fsync_buffers_list() submits a list of
      bios to dm_raid1, the bios are added to dm_raid1 write queue and kmirrord is
      woken up.
      
      fsync_buffers_list() calls wait_on_buffer().  That unplugs the queue, but
      there are no bios on the device queue as they are still in the dm_raid1 queue.
      
      wait_on_buffer() starts waiting until the IO is finished.
      
      kmirrord is scheduled, kmirrord takes bios and submits them to the devices.
      
      The submitted bio plugs the harddisk queue but there is no one to unplug it.
      (The process that called wait_on_buffer() is already sleeping.)
      
      So there is a 3ms timeout, after which the queues on the harddisks are
      unplugged and requests are processed.
      
      This 3ms timeout meant that in certain workloads (e.g. O_SYNC, 8kb writes),
      dm-raid1 is 10 times slower than md raid1.
      
      Every time we submit something asynchronously via dm_io, we must unplug the
      queue actually to send the request to the device.
      
      This patch adds an unplug call to kmirrord - while processing requests, it keeps
      the queue plugged (so that adjacent bios can be merged); when it finishes
      processing all the bios, it unplugs the queue to submit the bios.
      
      It also fixes kcopyd which has the same potential problem. All kcopyd requests
      are submitted with BIO_RW_SYNC.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      7ff14a36
    • A
      dm: move include files · a765e20e
      Alasdair G Kergon 提交于
      Publish the dm-io, dm-log and dm-kcopyd headers in include/linux.
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      a765e20e
    • H
      dm io: clean interface · 22a1ceb1
      Heinz Mauelshagen 提交于
      Clean up the dm-io interface to prepare for publishing it in include/linux.
      Signed-off-by: NHeinz Mauelshagen <hjm@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      22a1ceb1
    • A
      dm io: rename error to error_bits · e01fd7ee
      Alasdair G Kergon 提交于
      Rename 'error' to 'error_bits' for clarity.
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      e01fd7ee
  8. 29 3月, 2008 1 次提交
  9. 10 10月, 2007 1 次提交
  10. 13 7月, 2007 1 次提交
  11. 10 5月, 2007 4 次提交
  12. 30 4月, 2007 1 次提交
    • J
      [BLOCK] Don't pin lots of memory in mempools · 5972511b
      Jens Axboe 提交于
      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: NJens Axboe <jens.axboe@oracle.com>
      5972511b
  13. 09 12月, 2006 1 次提交
  14. 27 3月, 2006 1 次提交
  15. 09 10月, 2005 1 次提交
  16. 08 9月, 2005 1 次提交
  17. 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