linux-stable.git/drivers/md, branch linux-2.6.19.y

[PATCH] md: fix potential memalloc deadlock in md

2007-02-05T16:31:43+00:00

If a GFP_KERNEL allocation is attempted in md while the mddev_lock is
held, it is possible for a deadlock to eventuate.
This happens if the array was marked 'clean', and the memalloc triggers
a write-out to the md device.
For the writeout to succeed, the array must be marked 'dirty', and that
requires getting the mddev_lock.

So, before attempting a GFP_KERNEL alloction while holding the lock,
make sure the array is marked 'dirty' (unless it is currently read-only).

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright

[PATCH] md: fix a few problems with the interface (sysfs and ioctl) to md.

2007-02-05T16:31:43+00:00

While developing more functionality in mdadm I found some bugs in md...

- When we remove a device from an inactive array (write 'remove' to
  the 'state' sysfs file - see 'state_store') would should not
  update the superblock information - as we may not have
  read and processed it all properly yet.

- initialise all raid_disk entries to '-1' else the 'slot sysfs file
  will claim '0' for all devices in an array before the array is
  started.

- all '\n' not to be present at the end of words written to
  sysfs files
- when we use SET_ARRAY_INFO to set the md metadata version,
  set the flag to say that there is persistant metadata.
- allow GET_BITMAP_FILE to be called on an array that hasn't
  been started yet.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright

[PATCH] md: make 'repair' actually work for raid1.

2007-02-05T16:31:43+00:00

When 'repair' finds a block that is different one the various
parts of the mirror. it is meant to write a chosen good version
to the others.  However it currently writes out the original data
to each. The memcpy to make all the data the same is missing.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright

[PATCH] md: assorted md and raid1 one-liners

2007-02-05T16:31:43+00:00

Fix few bugs that meant that:
  - superblocks weren't alway written at exactly the right time (this
    could show up if the array was not written to - writting to the array
    causes lots of superblock updates and so hides these errors).

  - restarting device recovery after a clean shutdown (version-1 metadata
    only) didn't work as intended (or at all).

1/ Ensure superblock is updated when a new device is added.
2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync.
   The body of this if takes one of two branches depending on whether
   MD_RECOVERY_SYNC is set, so testing it in the clause of the if
   is wrong.
3/ Flag superblock for updating after a resync/recovery finishes.
4/ If we find the neeed to restart a recovery in the middle (version-1
   metadata only) make sure a full recovery (not just as guided by
   bitmaps) does get done.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright

[PATCH] md: pass down BIO_RW_SYNC in raid{1,10}

2007-02-05T16:31:39+00:00

md raidX make_request functions strip off the BIO_RW_SYNC flag, thus
introducing additional latency.

Fixing this in raid1 and raid10 seems to be straightforward enough.

For our particular usage case in DRBD, passing this flag improved some
initialization time from ~5 minutes to ~5 seconds.

Acked-by: NeilBrown 
Signed-off-by: Lars Ellenberg 
Acked-by: Jens Axboe 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Wright

[PATCH] dm-crypt: Select CRYPTO_CBC

2007-01-10T19:05:17+00:00

As CBC is the default chaining method for cryptoloop, we should select
it from cryptoloop to ease the transition.  Spotted by Rene Herman.

Signed-off-by: Herbert Xu 
Signed-off-by: Chris Wright

[PATCH] md: do not freeze md threads for suspend

2006-11-09T02:29:24+00:00

If there's a swap file on a software RAID, it should be possible to use this
file for saving the swsusp's suspend image.  Also, this file should be
available to the memory management subsystem when memory is being freed before
the suspend image is created.

For the above reasons it seems that md_threads should not be frozen during the
suspend and the appended patch makes this happen, but then there is the
question if they don't cause any data to be written to disks after the suspend
image has been created, provided that all filesystems are frozen at that time.

Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] md: fix sizing problem with raid5-reshape and CONFIG_LBD=n

2006-11-09T02:29:24+00:00

I forgot to has the size-in-blocks to (loff_t) before shifting up to a
size-in-bytes.

Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] md: change ONLINE/OFFLINE events to a single CHANGE event

2006-11-09T02:29:23+00:00

It turns out that CHANGE is preferred to ONLINE/OFFLINE for various reasons
(not least of which being that udev understands it already).

So remove the recently added KOBJ_OFFLINE (no-one is likely to care anyway)
and change the ONLINE to a CHANGE event

Cc: Kay Sievers 
Signed-off-by: Neil Brown 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] dm: raid1: fix waiting for io on suspend

2006-11-09T02:29:23+00:00

All device-mapper targets must complete outstanding I/O before suspending.
The mirror target generates I/O in its recovery phase and fails to wait for
it.  It needs to be tracked so we can ensure that it has completed before we
suspend.

[akpm@osdl.org: cleanup]
Signed-off-by: Jonathan E Brassow 
Signed-off-by: Alasdair G Kergon 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds