1. 30 4月, 2007 1 次提交
  2. 27 3月, 2007 1 次提交
    • V
      block: blk_max_pfn is somtimes wrong · f772b3d9
      Vasily Tarasov 提交于
      There is a small problem in handling page bounce.
      
      At the moment blk_max_pfn equals max_pfn, which is in fact not maximum
      possible _number_ of a page frame, but the _amount_ of page frames.  For
      example for the 32bit x86 node with 4Gb RAM, max_pfn = 0x100000, but not
      0xFFFF.
      
      request_queue structure has a member q->bounce_pfn and queue needs bounce
      pages for the pages _above_ this limit.  This routine is handled by
      blk_queue_bounce(), where the following check is produced:
      
      	if (q->bounce_pfn >= blk_max_pfn)
      		return;
      
      Assume, that a driver has set q->bounce_pfn to 0xFFFF, but blk_max_pfn
      equals 0x10000.  In such situation the check above fails and for each bio
      we always fall down for iterating over pages tied to the bio.
      
      I want to notice, that for quite a big range of device drivers (ide, md,
      ...) such problem doesn't happen because they use BLK_BOUNCE_ANY for
      bounce_pfn.  BLK_BOUNCE_ANY is defined as blk_max_pfn << PAGE_SHIFT, and
      then the check above doesn't fail.  But for other drivers, which obtain
      reuired value from drivers, it fails.  For example sata_nv uses
      ATA_DMA_MASK or dev->dma_mask.
      
      I propose to use (max_pfn - 1) for blk_max_pfn.  And the same for
      blk_max_low_pfn.  The patch also cleanses some checks related with
      bounce_pfn.
      Signed-off-by: NVasily Tarasov <vtaras@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      f772b3d9
  3. 10 2月, 2007 1 次提交
    • N
      [PATCH] md: fix various bugs with aligned reads in RAID5 · 387bb173
      Neil Brown 提交于
      It is possible for raid5 to be sent a bio that is too big for an underlying
      device.  So if it is a READ that we pass stright down to a device, it will
      fail and confuse RAID5.
      
      So in 'chunk_aligned_read' we check that the bio fits within the parameters
      for the target device and if it doesn't fit, fall back on reading through
      the stripe cache and making lots of one-page requests.
      
      Note that this is the earliest time we can check against the device because
      earlier we don't have a lock on the device, so it could change underneath
      us.
      
      Also, the code for handling a retry through the cache when a read fails has
      not been tested and was badly broken.  This patch fixes that code.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: "Kai" <epimetreus@fastmail.fm>
      Cc: <stable@suse.de>
      Cc: <org@suse.de>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      387bb173
  4. 23 12月, 2006 1 次提交
  5. 19 12月, 2006 5 次提交
  6. 13 12月, 2006 1 次提交
  7. 12 12月, 2006 1 次提交
    • B
      [PATCH] remove blk_queue_activity_fn · 2b02a179
      Boaz Harrosh 提交于
      While working on bidi support at struct request level
      I have found that blk_queue_activity_fn is actually never used.
      The only user is in ide-probe.c with this code:
      
      	/* enable led activity for disk drives only */
      	if (drive->media == ide_disk && hwif->led_act)
      		blk_queue_activity_fn(q, hwif->led_act, drive);
      
      And led_act is never initialized anywhere.
      (Looking back at older kernels it was used in the PPC arch, but was removed around 2.6.18)
      Unless it is all for future use off course.
      (this patch is against linux-2.6-block.git as off 2006/12/4)
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2b02a179
  8. 11 12月, 2006 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. 08 12月, 2006 2 次提交
  11. 01 12月, 2006 1 次提交
  12. 22 11月, 2006 1 次提交
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells 提交于
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
  13. 04 11月, 2006 1 次提交
  14. 01 11月, 2006 1 次提交
  15. 21 10月, 2006 2 次提交
  16. 05 10月, 2006 1 次提交
  17. 01 10月, 2006 16 次提交
  18. 30 9月, 2006 1 次提交
  19. 23 9月, 2006 1 次提交