linux-toradex.git/drivers/md, branch v2.6.23.12

raid5: fix unending write sequence

2007-11-26T17:42:28+00:00

patch 6c55be8b962f1bdc592d579e81fc27b11ea53dfc in mainline.


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


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: Dan Williams 
Tested-by: Joel Bertrand 
Cc: 
Cc: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

md: raid5: fix clearing of biofill operations

2007-11-16T17:30:22+00:00

raid5: fix clearing of biofill operations

This is the correct merge of the two upstream patches for this issue (it
was mis-merged...)

ops_complete_biofill() runs outside of spin_lock(&sh->lock) and clears the
'pending' and 'ack' bits.  Since the test_and_ack_op() macro only checks
against 'complete' it can get an inconsistent snapshot of pending work.

Move the clearing of these bits to handle_stripe5(), under the lock.

Signed-off-by: Dan Williams 
Tested-by: Joel Bertrand 
Signed-off-by: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

md: fix an unsigned compare to allow creation of bitmaps with v1.0 metadata

2007-11-16T17:30:22+00:00

patch 85bfb4da8cad483a4e550ec89060d05a4daf895b in mainline.

As page->index is unsigned, this all becomes an unsigned comparison, which
 almost always returns an error.

Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dm: fix thaw_bdev

2007-11-16T17:30:21+00:00

patch ae9da83f6d800fe1f3b23bfbc8f7222ad1c5bb74 in mainline.

This patch fixes a bd_mount_sem counter corruption bug in device-mapper.

thaw_bdev() should be called only when freeze_bdev() was called for the
device.
Otherwise, thaw_bdev() will up bd_mount_sem and corrupt the semaphore counter.
struct block_device with the corrupted semaphore may remain in slab cache
and be reused later.

Attached patch will fix it by calling unlock_fs() instead.
unlock_fs() will determine whether it should call thaw_bdev()
by checking the device is frozen or not.

Easy reproducer is:
  #!/bin/sh
  while [ 1 ]; do
     dmsetup --notable create a
     dmsetup --nolockfs suspend a
     dmsetup remove a
  done

It's not easy to see the effect of corrupted semaphore.
So I have tested with putting printk below in bdev_alloc_inode():
        if (atomic_read(&ei->bdev.bd_mount_sem.count) != 1)
                printk(KERN_DEBUG "Incorrect semaphore count = %d (%p)\n",
                        atomic_read(&ei->bdev.bd_mount_sem.count),
                        &ei->bdev);

Without the patch, I saw something like:
 Incorrect semaphore count = 17 (f2ab91c0)

With the patch, the message didn't appear.

The bug was introduced in 2.6.16 with this bug fix:

commit d9dde59ba03095e526640988c0fedd75e93bc8b7
Date:   Fri Feb 24 13:04:24 2006 -0800

    [PATCH] dm: missing bdput/thaw_bdev at removal
    
    Need to unfreeze and release bdev otherwise the bdev inode with
    inconsistent state is reused later and cause problem.
    
and backported to 2.6.15.5.

It occurs only in free_dev(), which is called only when the dm device is
removed.  The buggy code is executed only if md->suspended_bdev is
non-NULL and that can happen only when the device was suspended without
noflush.

Signed-off-by: Jun'ichi Nomura 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

dm delay: fix status

2007-11-16T17:30:21+00:00

patch 79662d1ea37392651f2cff08626cab6a40ba3adc in mainline.


Fix missing space in dm-delay target status output
if separate read and write delay are configured.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

raid5: fix 2 bugs in ops_complete_biofill

2007-09-24T20:23:35+00:00

1/ ops_complete_biofill tried to avoid calling handle_stripe since all the
state necessary to return read completions is available.  However the
process of determining whether more read requests are pending requires
locking the stripe (to block add_stripe_bio from updating dev->toead).
ops_complete_biofill can run in tasklet context, so rather than upgrading
all the stripe locks from spin_lock to spin_lock_bh this patch just
unconditionally reschedules handle_stripe after completing the read
request.

2/ ops_complete_biofill needlessly qualified processing R5_Wantfill with
dev->toread.  The result being that the 'biofill' pending bit is cleared
before handling the pending read-completions on dev->read.  R5_Wantfill can
be unconditionally handled because the 'biofill' pending bit prevents new
R5_Wantfill requests from being seen by ops_run_biofill and
ops_complete_biofill.

Found-by: Yuri Tikhonov 
[neilb@suse.de: simpler fix for bug 1 than moving code]
Signed-off-by: NeilBrown 
Signed-off-by: Dan Williams

Fix kernel buuild with (CONFIG_COMPAT && ! CONFIG_BLOCK)

2007-09-14T20:56:47+00:00

Commit 02a5e0acb3cb85d80d0fe834e366d38a92bbaa22 ("BLOCK: Hide the
contents of linux/bio.h if CONFIG_BLOCK=n") broke the kernel build for
the CONFIG_COMPAT && !CONFIG_BLOCK case:

    CC      fs/compat_ioctl.o
  In file included from include/linux/raid/md_k.h:19,
                   from include/linux/raid/md.h:54,
                   from fs/compat_ioctl.c:25:
  include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
  include/linux/raid/../../../drivers/md/dm-bio-list.h:40: error: dereferencing pointer to incomplete type
  include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
  include/linux/raid/../../../drivers/md/dm-bio-list.h:48: error: dereferencing pointer to incomplete type
  include/linux/raid/../../../drivers/md/dm-bio-list.h:51: error: dereferencing pointer to incomplete type
  include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
  include/linux/raid/../../../drivers/md/dm-bio-list.h:64: error: dereferencing pointer to incomplete type
  include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_merge_:
  include/linux/raid/../../../drivers/md/dm-bio-list.h:78: error: dereferencing pointer to incomplete type
  include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
  include/linux/raid/../../../drivers/md/dm-bio-list.h:90: error: dereferencing pointer to incomplete type
  include/linux/raid/../../../drivers/md/dm-bio-list.h:94: error: dereferencing pointer to incomplete type
  make[1]: *** [fs/compat_ioctl.o] Error 1
  make: *** [fs] Error 2

Signed-off-by: Andreas Herrmann 
Acked-By: David Howells 
Signed-off-by: Linus Torvalds

md: fix some bugs with growing raid5/raid6 arrays.

2007-09-12T00:21:19+00:00

The recent changed to raid5 to allow offload of parity calculation etc
introduced some bugs in the code for growing (i.e.  adding a disk to) raid5
and raid6.  This fixes them

Acked-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dm-mpath-rdac: don't stomp on a requests transfer bit

2007-08-27T23:15:44+00:00

Without this, we get qla2xxx complaining about "ISP System Error".

What's happening here is the firmware is detecting a Xfer-ready from the
storage when in fact the data-direction for a mode-select should be a
write (DATA_OUT).

The following patch fixes the problem (typo). Verified by Brian, as
well.

Signed-off-by: Andrew Vasquez 
Verified-by: Brian De Wolf 
Signed-off-by: Chandra Seetharaman 
Signed-off-by: Linus Torvalds

DM_MULTIPATH_RDAC: "scsi_normalize_sense" undefined

2007-08-24T23:10:39+00:00

DM_MULTIPATH_RDAC uses SCSI API(s) and is for a SCSI device,
so add SCSI to its depends on to prevent build errors.

Signed-off-by: Randy Dunlap 
[ Tested and Verified by Chandra Seetharaman ]
Acked-by: Chandra Seetharaman 
Signed-off-by: Linus Torvalds