1. 27 7月, 2012 2 次提交
  2. 29 3月, 2012 1 次提交
    • M
      dm: reject trailing characters in sccanf input · 31998ef1
      Mikulas Patocka 提交于
      Device mapper uses sscanf to convert arguments to numbers. The problem is that
      the way we use it ignores additional unmatched characters in the scanned string.
      
      For example, this `if (sscanf(string, "%d", &number) == 1)' will match a number,
      but also it will match number with some garbage appended, like "123abc".
      
      As a result, device mapper accepts garbage after some numbers. For example
      the command `dmsetup create vg1-new --table "0 16384 linear 254:1bla 34816bla"'
      will pass without an error.
      
      This patch fixes all sscanf uses in device mapper. It appends "%c" with
      a pointer to a dummy character variable to every sscanf statement.
      
      The construct `if (sscanf(string, "%d%c", &number, &dummy) == 1)' succeeds
      only if string is a null-terminated number (optionally preceded by some
      whitespace characters). If there is some character appended after the number,
      sscanf matches "%c", writes the character to the dummy variable and returns 2.
      We check the return value for 1 and consequently reject numbers with some
      garbage appended.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Acked-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      31998ef1
  3. 24 3月, 2011 1 次提交
    • M
      dm stripe: implement merge method · 29915202
      Mustafa Mesanovic 提交于
      Implement a merge function in the striped target.
      
      When the striped target's underlying devices provide a merge_bvec_fn
      (like all DM devices do via dm_merge_bvec) it is important to call down
      to them when building a biovec that doesn't span a stripe boundary.
      
      Without the merge method, a striped DM device stacked on DM devices
      causes bios with a single page to be submitted which results
      in unnecessary overhead that hurts performance.
      
      This change really helps filesystems (e.g. XFS and now ext4) which take
      care to assemble larger bios.  By implementing stripe_merge(), DM and the
      stripe target no longer undermine the filesystem's work by only allowing
      a single page per bio.  Buffered IO sees the biggest improvement
      (particularly uncached reads, buffered writes to a lesser degree).  This
      is especially so for more capable "enterprise" storage LUNs.
      
      The performance improvement has been measured to be ~12-35% -- when a
      reasonable chunk_size is used (e.g. 64K) in conjunction with a stripe
      count that is a power of 2.
      
      In contrast, the performance penalty is ~5-7% for the pathological worst
      case stripe configuration (small chunk_size with a stripe count that is
      not a power of 2).  The reason for this is that stripe_map_sector() is
      now called once for every call to dm_merge_bvec().  stripe_map_sector()
      will use slower division if stripe count isn't a power of 2.
      Signed-off-by: NMustafa Mesanovic <mume@linux.vnet.ibm.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      29915202
  4. 14 1月, 2011 1 次提交
  5. 10 9月, 2010 1 次提交
    • T
      dm: implement REQ_FLUSH/FUA support for bio-based dm · d87f4c14
      Tejun Heo 提交于
      This patch converts bio-based dm to support REQ_FLUSH/FUA instead of
      now deprecated REQ_HARDBARRIER.
      
      * -EOPNOTSUPP handling logic dropped.
      
      * Preflush is handled as before but postflush is dropped and replaced
        with passing down REQ_FUA to member request_queues.  This replaces
        one array wide cache flush w/ member specific FUA writes.
      
      * __split_and_process_bio() now calls __clone_and_map_flush() directly
        for flushes and guarantees all FLUSH bio's going to targets are zero
      `  length.
      
      * It's now guaranteed that all FLUSH bio's which are passed onto dm
        targets are zero length.  bio_empty_barrier() tests are replaced
        with REQ_FLUSH tests.
      
      * Empty WRITE_BARRIERs are replaced with WRITE_FLUSHes.
      
      * Dropped unlikely() around REQ_FLUSH tests.  Flushes are not unlikely
        enough to be marked with unlikely().
      
      * Block layer now filters out REQ_FLUSH/FUA bio's if the request_queue
        doesn't support cache flushing.  Advertise REQ_FLUSH | REQ_FUA
        capability.
      
      * Request based dm isn't converted yet.  dm_init_request_based_queue()
        resets flush support to 0 for now.  To avoid disturbing request
        based dm code, dm->flush_error is added for bio based dm while
        requested based dm continues to use dm->barrier_error.
      
      Lightly tested linear, stripe, raid1, snap and crypt targets.  Please
      proceed with caution as I'm not familiar with the code base.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: dm-devel@redhat.com
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      d87f4c14
  6. 12 8月, 2010 5 次提交
  7. 08 8月, 2010 1 次提交
    • C
      block: unify flags for struct bio and struct request · 7b6d91da
      Christoph Hellwig 提交于
      Remove the current bio flags and reuse the request flags for the bio, too.
      This allows to more easily trace the type of I/O from the filesystem
      down to the block driver.  There were two flags in the bio that were
      missing in the requests:  BIO_RW_UNPLUG and BIO_RW_AHEAD.  Also I've
      renamed two request flags that had a superflous RW in them.
      
      Note that the flags are in bio.h despite having the REQ_ name - as
      blkdev.h includes bio.h that is the only way to go for now.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      7b6d91da
  8. 06 3月, 2010 1 次提交
  9. 17 2月, 2010 1 次提交
  10. 14 9月, 2009 1 次提交
  11. 11 9月, 2009 1 次提交
  12. 05 9月, 2009 1 次提交
  13. 24 7月, 2009 1 次提交
  14. 22 6月, 2009 2 次提交
  15. 06 1月, 2009 1 次提交
    • M
      dm: consolidate target deregistration error handling · 10d3bd09
      Mikulas Patocka 提交于
      Change dm_unregister_target to return void and use BUG() for error
      reporting.
      
      dm_unregister_target can only fail because of programming bug in the
      target driver. It can't fail because of user's behavior or disk errors.
      
      This patch changes unregister_target to return void and use BUG if
      someone tries to unregister non-registered target or unregister target
      that is in use.
      
      This patch removes code duplication (testing of error codes in all dm
      targets) and reports bugs in just one place, in dm_unregister_target. In
      some target drivers, these return codes were ignored, which could lead
      to a situation where bugs could be missed.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      10d3bd09
  16. 14 11月, 2008 1 次提交
  17. 22 10月, 2008 2 次提交
  18. 09 10月, 2008 1 次提交
    • T
      block: don't depend on consecutive minor space · f331c029
      Tejun Heo 提交于
      * Implement disk_devt() and part_devt() and use them to directly
        access devt instead of computing it from ->major and ->first_minor.
      
        Note that all references to ->major and ->first_minor outside of
        block layer is used to determine devt of the disk (the part0) and as
        ->major and ->first_minor will continue to represent devt for the
        disk, converting these users aren't strictly necessary.  However,
        convert them for consistency.
      
      * Implement disk_max_parts() to avoid directly deferencing
        genhd->minors.
      
      * Update bdget_disk() such that it doesn't assume consecutive minor
        space.
      
      * Move devt computation from register_disk() to add_disk() and make it
        the only one (all other usages use the initially determined value).
      
      These changes clean up the code and will help disk->part dereference
      fix and extended block device numbers.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      f331c029
  19. 08 2月, 2008 2 次提交
    • B
      dm: stripe enhanced status return · 4f7f5c67
      Brian Wood 提交于
      This patch adds additional information to the status line. It is added at the
      end of the returned text so it will not interfere with existing
      implementations using this data. The addition of this information will allow
      for a common return interface to match that returned with the dm-raid1.c
      status line (with Jonathan Brassow's patches).
      
      Here is a sample of what is returned with a mirror "status" call:
      isw_eeaaabgfg_mirror: 0 488390920 mirror 2 8:16 8:32 3727/3727 1 AA 1 core
      
      Here's what's returned with this patch for a stripe "status" call:
      isw_dheeijjdej_stripe: 0 976783872 striped 2 8:16 8:32 1 AA
      Signed-off-by: NBrian Wood <brian.j.wood@intel.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      4f7f5c67
    • B
      dm: stripe trigger event on failure · a25eb944
      Brian Wood 提交于
      This patch adds the stripe_end_io function to process errors that might
      occur after an IO operation. As part of this there are a number of
      enhancements made to record and trigger events:
      
      - New atomic variable in struct stripe to record the number of
      errors each stripe volume device has experienced (could be used
      later with uevents to report back directly to userspace)
      
      - New workqueue/work struct setup to process the trigger_event function
      
      - New end_io function. It is here that testing for BIO error conditions
      take place. It determines the exact stripe that cause the error,
      records this in the new atomic variable, and calls the queue_work() function
      
      - New trigger_event function to process failure events. This
      calls dm_table_event()
      Signed-off-by: NBrian Wood <brian.j.wood@intel.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      a25eb944
  20. 20 10月, 2007 1 次提交
  21. 09 12月, 2006 1 次提交
  22. 27 6月, 2006 1 次提交
  23. 28 3月, 2006 2 次提交
  24. 17 3月, 2006 1 次提交
    • K
      [PATCH] dm stripe: Fix bounds · 8ba32fde
      Kevin Corry 提交于
      The dm-stripe target currently does not enforce that the size of a stripe
      device be a multiple of the chunk-size.  Under certain conditions, this can
      lead to I/O requests going off the end of an underlying device.  This
      test-case shows one example.
      
      echo "0 100 linear /dev/hdb1 0" | dmsetup create linear0
      echo "0 100 linear /dev/hdb1 100" | dmsetup create linear1
      echo "0 200 striped 2 32 /dev/mapper/linear0 0 /dev/mapper/linear1 0" | \
         dmsetup create stripe0
      dd if=/dev/zero of=/dev/mapper/stripe0 bs=1k
      
      This will produce the output:
      dd: writing '/dev/mapper/stripe0': Input/output error
      97+0 records in
      96+0 records out
      
      And in the kernel log will be:
      attempt to access beyond end of device
      dm-0: rw=0, want=104, limit=100
      
      The patch will check that the table size is a multiple of the stripe
      chunk-size when the table is created, which will prevent the above striped
      device from being created.
      
      This should not affect tools like LVM or EVMS, since in all the cases I can
      think of, striped devices are always created with the sizes being a
      multiple of the chunk-size.
      
      The size of a stripe device must be a multiple of its chunk-size.
      
      (akpm: that typecast is quite gratuitous)
      Signed-off-by: NKevin Corry <kevcorry@us.ibm.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8ba32fde
  25. 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