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

dm ioctl: release _hash_lock between devices in remove_all

2010-08-26T23:43:37+00:00

commit 98f332855effef02aeb738e4d62e9a5b903c52fd upstream.

This patch changes dm_hash_remove_all() to release _hash_lock when
removing a device.  After removing the device, dm_hash_remove_all()
takes _hash_lock and searches the hash from scratch again.

This patch is a preparation for the next patch, which changes device
deletion code to wait for md reference to be 0.  Without this patch,
the wait in the next patch may cause AB-BA deadlock:
  CPU0                                CPU1
  -----------------------------------------------------------------------
  dm_hash_remove_all()
    down_write(_hash_lock)
                                      table_status()
                                        md = find_device()
                                               dm_get(md)
                                                 holders>
                                        dm_get_live_or_inactive_table()
                                          dm_get_inactive_table()
                                            down_write(_hash_lock)
    
      holders to be 0>

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

dm: prevent access to md being deleted

2010-08-26T23:43:36+00:00

commit abdc568b0540bec6d3e0afebac496adef1189b77 upstream.

This patch prevents access to mapped_device which is being deleted.

Currently, even after a mapped_device has been removed from the hash,
it could be accessed through idr_find() using minor number.
That could cause a race and NULL pointer reference below:
  CPU0                          CPU1
  ------------------------------------------------------------------
  dev_remove(param)
    down_write(_hash_lock)
    dm_lock_for_deletion(md)
      spin_lock(_minor_lock)
      set_bit(DMF_DELETING)
      spin_unlock(_minor_lock)
    __hash_remove(hc)
    up_write(_hash_lock)
                                dev_status(param)
                                  md = find_device(param)
                                         down_read(_hash_lock)
                                         __find_device_hash_cell(param)
                                           dm_get_md(param->dev)
                                             md = dm_find_md(dev)
                                                    spin_lock(_minor_lock)
                                                    md = idr_find(MINOR(dev))
                                                    spin_unlock(_minor_lock)
    dm_put(md)
      free_dev(md)
                                             dm_get(md)
                                         up_read(_hash_lock)
                                  __dev_status(md, param)
                                  dm_put(md)

This patch fixes such problems.

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

dm snapshot: test chunk size against both origin and snapshot

2010-08-26T23:43:35+00:00

commit c24110450650f17f7d3ba4fbe01f01ac5a115456 upstream.

Validate chunk size against both origin and snapshot sector size

Don't allow chunk size smaller than either origin or snapshot logical
sector size. Reading or writing data not aligned to sector size is not
allowed and causes immediate errors.

This requires us to open the origin before initialising the
exception store and to export dm_snap_origin.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

dm snapshot: iterate origin and cow devices

2010-08-26T23:43:35+00:00

commit 1e5554c8428bc7209a83e2d07ca724be4d981ce3 upstream.

Iterate both origin and snapshot devices

iterate_devices method should call the callback for all the devices where
the bio may be remapped. Thus, snapshot_iterate_devices should call the callback
for both snapshot and origin underlying devices because it remaps some bios
to the snapshot and some to the origin.

snapshot_iterate_devices called the callback only for the origin device.
This led to badly calculated device limits if snapshot and origin were placed
on different types of disks.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

dm mpath: fix NULL pointer dereference when path parameters missing

2010-08-26T23:43:35+00:00

commit 6bbf79a14080a0c61212f53b4b87dc1a99fedf9c upstream.

multipath_ctr() forgets to return an error after detecting
missing path parameters.  Fix this.

Signed-off-by: Patrick LoPresti 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

md/raid1: delay reads that could overtake behind-writes.

2010-08-13T20:27:37+00:00

commit e555190d82c0f58e825e3cbd9e6ebe2e7ac713bd upstream.

When a raid1 array is configured to support write-behind
on some devices, it normally only reads from other devices.
If all devices are write-behind (because the rest have failed)
it is possible for a read request to be serviced before a
behind-write request, which would appear as data corruption.

So when forced to read from a WriteMostly device, wait for any
write-behind to complete, and don't start any more behind-writes.

Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: fix deadlock with unaligned read during resync

2010-08-13T20:27:20+00:00

commit 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 upstream.

If the 'bio_split' path in raid10-read is used while
resync/recovery is happening it is possible to deadlock.
Fix this be elevating ->nr_waiting for the duration of both
parts of the split request.

This fixes a bug that has been present since 2.6.22
but has only started manifesting recently for unknown reasons.
It is suitable for and -stable since then.

Reported-by:  Justin Bronder 
Tested-by:  Justin Bronder 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: raid10: Fix null pointer dereference in fix_read_error()

2010-08-02T17:29:42+00:00

commit 0544a21db02c1d8883158fd6f323364f830a120a upstream.

Such NULL pointer dereference can occur when the driver was fixing the
read errors/bad blocks and the disk was physically removed
causing a system crash. This patch check if the
rcu_dereference() returns valid rdev before accessing it in fix_read_error().

Signed-off-by: Prasanna S. Panchamukhi 
Signed-off-by: Rob Becker 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: manage redundancy group in sysfs when changing level.

2010-07-05T18:22:30+00:00

commit a64c876fd357906a1f7193723866562ad290654c upstream.

Some levels expect the 'redundancy group' to be present,
others don't.
So when we change level of an array we might need to
add or remove this group.

This requires fixing up the current practice of overloading ->private
to indicate (when ->pers == NULL) that something needs to be removed.
So create a new ->to_remove to fill that role.

When changing levels, we may need to add or remove attributes.  When
changing RAID5 -> RAID6, we both add and remove the same thing.  It is
important to catch this and optimise it out as the removal is delayed
until a lock is released, so trying to add immediately would cause
problems.


Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: set mddev readonly flag on blkdev BLKROSET ioctl

2010-07-05T18:22:24+00:00

commit e2218350465e7e0931676b4849b594c978437bce upstream.

When the user sets the block device to readwrite then the mddev should
follow suit.  Otherwise, the BUG_ON in md_write_start() will be set to
trigger.

The reverse direction, setting mddev->ro to match a set readonly
request, can be ignored because the blkdev level readonly flag precludes
the need to have mddev->ro set correctly.  Nevermind the fact that
setting mddev->ro to 1 may fail if the array is in use.

Signed-off-by: Dan Williams 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman