1. 08 2月, 2008 9 次提交
  2. 07 2月, 2008 17 次提交
  3. 25 1月, 2008 6 次提交
  4. 09 1月, 2008 1 次提交
  5. 21 12月, 2007 6 次提交
    • M
      dm crypt: use bio_add_page · 91e10625
      Milan Broz 提交于
      Fix possible max_phys_segments violation in cloned dm-crypt bio.
      
      In write operation dm-crypt needs to allocate new bio request
      and run crypto operation on this clone. Cloned request has always
      the same size, but number of physical segments can be increased
      and violate max_phys_segments restriction.
      
      This can lead to data corruption and serious hardware malfunction.
      This was observed when using XFS over dm-crypt and at least
      two HBA controller drivers (arcmsr, cciss) recently.
      
      Fix it by using bio_add_page() call (which tests for other
      restrictions too) instead of constructing own biovec.
      
      All versions of dm-crypt are affected by this bug.
      
      Cc: stable@kernel.org
      Cc:  dm-crypt@saout.de
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      91e10625
    • N
      dm: merge max_hw_sector · 91212507
      Neil Brown 提交于
      Make sure dm honours max_hw_sectors of underlying devices
      
        We still have no firm testing evidence in support of this patch but
        believe it may help to resolve some bug reports.  - agk
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      91212507
    • A
      dm: trigger change uevent on rename · 69267a30
      Alasdair G Kergon 提交于
      Insert a missing KOBJ_CHANGE notification when a device is renamed.
      
      Cc: Scott James Remnant <scott@ubuntu.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      69267a30
    • M
      dm crypt: fix write endio · adfe4770
      Milan Broz 提交于
      Fix BIO_UPTODATE test for write io.
      
      Cc: stable@kernel.org
      Cc: dm-crypt@saout.de
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      adfe4770
    • 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
  6. 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