1. 13 10月, 2007 1 次提交
    • K
      Driver core: change add_uevent_var to use a struct · 7eff2e7a
      Kay Sievers 提交于
      This changes the uevent buffer functions to use a struct instead of a
      long list of parameters. It does no longer require the caller to do the
      proper buffer termination and size accounting, which is currently wrong
      in some places. It fixes a known bug where parts of the uevent
      environment are overwritten because of wrong index calculations.
      
      Many thanks to Mathieu Desnoyers for finding bugs and improving the
      error handling.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      7eff2e7a
  2. 18 7月, 2007 3 次提交
  3. 24 5月, 2007 2 次提交
  4. 10 5月, 2007 1 次提交
  5. 03 5月, 2007 1 次提交
  6. 05 4月, 2007 1 次提交
  7. 21 2月, 2007 1 次提交
  8. 13 2月, 2007 1 次提交
  9. 09 12月, 2006 1 次提交
    • A
      [PATCH] fault-injection capability for disk IO · c17bb495
      Akinobu Mita 提交于
      This patch provides fault-injection capability for disk IO.
      
      Boot option:
      
      fail_make_request=<probability>,<interval>,<space>,<times>
      
      	<interval> -- specifies the interval of failures.
      
      	<probability> -- specifies how often it should fail in percent.
      
      	<space> -- specifies the size of free space where disk IO can be issued
      		   safely in bytes.
      
      	<times> -- specifies how many times failures may happen at most.
      
      Debugfs:
      
      /debug/fail_make_request/interval
      /debug/fail_make_request/probability
      /debug/fail_make_request/specifies
      /debug/fail_make_request/times
      
      Example:
      
      	fail_make_request=10,100,0,-1
      	echo 1 > /sys/blocks/hda/hda1/make-it-fail
      
      generic_make_request() on /dev/hda1 fails once per 10 times.
      
      Cc: Jens Axboe <axboe@suse.de>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c17bb495
  10. 30 9月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 22 6月, 2006 1 次提交
  13. 13 5月, 2006 1 次提交
    • L
      Revert "[BLOCK] Fix oops on removal of SD/MMC card" · 1a2acc9e
      Linus Torvalds 提交于
      This reverts commit 56cf6504.
      
      Both Erik Mouw and Andrew Vasquez independently pinpointed this commit
      as causing problems, where the slab cache for a driver is never released
      (most obviously causing problems when immediately re-loading that
      driver, resulting in a "kmem_cache_create: duplicate cache <xyz>"
      message, but it can also cause other trouble).
      
      James Bottomley dug into it, and reports:
      
        "OK, here's the scoop.  The problem patch adds a get of driverfs_dev in
         add_disk(), but doesn't put it again until disk_release() (which occurs
         on final put_disk() of the gendisk).
      
         However, in SCSI, the driverfs_dev is the sdev_gendev.  That means
         there's a reference held on sdev_gendev  until final disk put.
         Unfortunately, we use the driver model driver_remove to trigger
         del_gendisk (which removes the gendisk from visibility and decrements
         the refcount), so we've introduced an unbreakable deadlock in the
         reference counting with this.
      
         I suggest simply reversing this patch at the moment.  If Russell and
         Jens can tell me what they're trying to do I'll see if there's another
         way to do it."
      
      so hereby the patch gets reverted, waiting for a better fix.
      
      Cc: Jens Axboe <axboe@suse.de>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: James Bottomley <James.Bottomley@SteelEye.com>
      Cc: Erik Mouw <erik@harddisk-recovery.com>
      Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1a2acc9e
  14. 06 5月, 2006 1 次提交
    • R
      [BLOCK] Fix oops on removal of SD/MMC card · 56cf6504
      Russell King 提交于
      The block layer keeps a reference (driverfs_dev) to the struct
      device associated with the block device, and uses it internally
      for generating uevents in block_uevent.
      
      Block device uevents include umounting the partition, which can
      occur after the backing device has been removed.
      
      Unfortunately, this reference is not counted.  This means that
      if the struct device is removed from the device tree, the block
      layers reference will become stale.
      
      Guard against this by holding a reference to the struct device
      in add_disk(), and only drop the reference when we're releasing
      the gendisk kobject - in other words when we can be sure that no
      further uevents will be generated for this block device.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NJens Axboe <axboe@suse.de>
      56cf6504
  15. 01 4月, 2006 1 次提交
  16. 27 3月, 2006 1 次提交
    • B
      [BLOCK] increase size of disk stat counters · 837c7878
      Ben Woodard 提交于
      The kernel's representation of the disk statistics uses the type unsigned
      which is 32b on both 32b and 64b platforms.  Unfortunately, most system
      tools that work with these numbers that are exported in /proc/diskstats
      including iostat read these numbers into unsigned longs.  This works fine
      on 32b platforms and when the number of IO transactions are small on 64b
      platforms.  However, when the numbers wrap on 64b platforms & you read the
      numbers into unsigned longs, and compare the numbers to previous readings,
      then you get an unsigned representation of a negative number.  This looks
      like a very large 64b number & gives you bizarre readouts in iostat:
      
      ilc4: Device:    rrqm/s wrqm/s r/s    w/s  rsec/s  wsec/s    rkB/s wkB/s avgrq-sz avgqu-sz   await  svctm  %util
      ilc4: sda        5.50   0.00   143.96 0.00 307496983987862656.00 0.00 153748491993931328.00     0.00 2136028725038430.00     7.94   55.12    5.59  80.42
      
      Though fixing iostat in user space is possible, and a quick survey
      indicates that several other similar tools also use unsigned longs when
      processing /proc/diskstats.  Therefore, it seems like a better approach
      would be to extend the length of the disk_stats structure on 64b
      architectures to 64b.  The following patch does that.  It should not affect
      the operation on 32b platforms.
      Signed-off-by: NBen Woodard <woodard@redhat.com>
      Cc: Rick Lindsley <ricklind@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NJens Axboe <axboe@suse.de>
      837c7878
  17. 21 3月, 2006 1 次提交
  18. 15 1月, 2006 1 次提交
  19. 05 1月, 2006 1 次提交
  20. 12 11月, 2005 1 次提交
  21. 04 11月, 2005 1 次提交
  22. 01 11月, 2005 1 次提交
    • J
      [BLOCK] Unify the seperate read/write io stat fields into arrays · a362357b
      Jens Axboe 提交于
      Instead of having ->read_sectors and ->write_sectors, combine the two
      into ->sectors[2] and similar for the other fields. This saves a branch
      several places in the io path, since we don't have to care for what the
      actual io direction is. On my x86-64 box, that's 200 bytes less text in
      just the core (not counting the various drivers).
      Signed-off-by: NJens Axboe <axboe@suse.de>
      a362357b
  23. 29 10月, 2005 1 次提交
  24. 08 9月, 2005 1 次提交
  25. 24 6月, 2005 2 次提交
  26. 21 6月, 2005 1 次提交
  27. 06 5月, 2005 1 次提交
  28. 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