1. 21 12月, 2007 2 次提交
    • P
      dm mpath: hp requires scsi · d1622e89
      Paul Mundt 提交于
      With CONFIG_SCSI=n __scsi_print_sense() is never linked in.
      
      drivers/built-in.o: In function `hp_sw_end_io':
      dm-mpath-hp-sw.c:(.text+0x914f8): undefined reference to `__scsi_print_sense'
      
      Caught with a randconfig on current git.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      d1622e89
    • J
      dm: table detect io beyond device · 512875bd
      Jun'ichi Nomura 提交于
      This patch fixes a panic on shrinking a DM device if there is
      outstanding I/O to the part of the device that is being removed.
      (Normally this doesn't happen - a filesystem would be resized first,
      for example.)
      
      The bug is that __clone_and_map() assumes dm_table_find_target()
      always returns a valid pointer.  It may fail if a bio arrives from the
      block layer but its target sector is no longer included in the DM
      btree.
      
      This patch appends an empty entry to table->targets[] which will
      be returned by a lookup beyond the end of the device.
      
      After calling dm_table_find_target(), __clone_and_map() and target_message()
      check for this condition using
      dm_target_is_valid().
      
      Sample test script to trigger oops:
      512875bd
  2. 15 11月, 2007 1 次提交
    • D
      raid5: fix unending write sequence · 6c55be8b
      Dan Williams 提交于
      <debug output from Joel's system>
      handling stripe 7629696, state=0x14 cnt=1, pd_idx=2 ops=0:0:0
      check 5: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800ffcffcc0 written 0000000000000000
      check 4: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800fdd4e360 written 0000000000000000
      check 3: state 0x1 toread 0000000000000000 read 0000000000000000 write 0000000000000000 written 0000000000000000
      check 2: state 0x1 toread 0000000000000000 read 0000000000000000 write 0000000000000000 written 0000000000000000
      check 1: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800ff517e40 written 0000000000000000
      check 0: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800fd4cae60 written 0000000000000000
      locked=4 uptodate=2 to_read=0 to_write=4 failed=0 failed_num=0
      for sector 7629696, rmw=0 rcw=0
      </debug>
      
      These blocks were prepared to be written out, but were never handled in
      ops_run_biodrain(), so they remain locked forever.  The operations flags
      are all clear which means handle_stripe() thinks nothing else needs to be
      done.
      
      This state suggests that the STRIPE_OP_PREXOR bit was sampled 'set' when it
      should not have been.  This patch cleans up cases where the code looks at
      sh->ops.pending when it should be looking at the consistent stack-based
      snapshot of the operations flags.
      
      Report from Joel:
      	Resync done. Patch fix this bug.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Tested-by: NJoel Bertrand <joel.bertrand@systella.fr>
      Cc: <stable@kernel.org>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6c55be8b
  3. 09 11月, 2007 1 次提交
  4. 06 11月, 2007 1 次提交
  5. 02 11月, 2007 1 次提交
  6. 29 10月, 2007 1 次提交
  7. 27 10月, 2007 1 次提交
  8. 24 10月, 2007 1 次提交
  9. 23 10月, 2007 3 次提交
  10. 20 10月, 2007 28 次提交