]> git.baikalelectronics.ru Git - kernel.git/commit
dm raid: fix data corruption on reshape request
authorHeinz Mauelshagen <heinzm@redhat.com>
Tue, 28 Feb 2017 18:17:49 +0000 (19:17 +0100)
committerMike Snitzer <snitzer@redhat.com>
Tue, 28 Feb 2017 21:47:51 +0000 (16:47 -0500)
commit6ee79dd7ec59335c7787a7cb3eedf034fd85dccd
tree9b33a36efb095df58d9408fb203abf82423bff12
parentefe40462f0c1b882b288e1f3204e2744affbe160
dm raid: fix data corruption on reshape request

The lvm2 sequence to manage dm-raid constructor flags that trigger a
rebuild or a reshape is defined as:

1) load table with flags (e.g. rebuild/delta_disks/data_offset)
2) clear out the flags in lvm2 metadata
3) store the lvm2 metadata, reload the table to reset the flags
   previously established during the initial load (1) -- in order to
   prevent repeatedly requesting a rebuild or a reshape on activation

Currently, loading an inactive table with rebuild/reshape flags
specified will cause dm-raid to rebuild/reshape on resume and thus start
updating the raid metadata (about the progress).  When the second table
reload, to reset the flags, occurs the constructor accesses the volatile
progress state kept in the raid superblocks.  Because the active mapping
is still processing the rebuild/reshape, that position will be stale by
the time the device is resumed.

In the reshape case, this causes data corruption by processing already
reshaped stripes again.  In the rebuild case, it does _not_ cause data
corruption but instead involves superfluous rebuilds.

Fix by keeping the raid set frozen during the first resume and then
allow the rebuild/reshape during the second resume.

Fixes: e294b8884 ("dm raid: add reshaping support to the target")
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
drivers/md/dm-raid.c