linux-toradex.git/drivers/md/dm-snap.c, branch v2.6.32.19

dm snapshot: cope with chunk size larger than origin

2009-12-18T22:05:02+00:00

commit 8e87b9b81b3c370f7e53c1ab6e1c3519ef37a644 upstream.

Under some special conditions the snapshot hash_size is calculated as zero.
This patch instead sets a minimum value of 64, the same as for the
pending exception table.

rounddown_pow_of_two(0) is an undefined operation (it expands to shift
by -1).  init_exception_table with an argument of 0 would fail with -ENOMEM.

The way to trigger the problem is to create a snapshot with a chunk size
that is larger than the origin device.

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

dm snapshot: only take lock for statustype info not table

2009-12-18T22:04:59+00:00

commit 94e76572b5dd37b1f0f4b3742ee8a565daead932 upstream.

Take snapshot lock only for STATUSTYPE_INFO, not STATUSTYPE_TABLE.

Commit 4c6fff445d7aa753957856278d4d93bcad6e2c14
(dm-snapshot-lock-snapshot-while-supplying-status.patch)
introduced this use of the lock, but userspace applications using
libdevmapper have been found to request STATUSTYPE_TABLE while the device
is suspended and the lock is already held, leading to deadlock.  Since
the lock is not necessary in this case, don't try to take it.

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

dm snapshot: use unsigned integer chunk size

2009-10-16T22:18:17+00:00

Use unsigned integer chunk size.

Maximum chunk size is 512kB, there won't ever be need to use 4GB chunk size,
so the number can be 32-bit. This fixes compiler failure on 32-bit systems
with large block devices.

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Reviewed-by: Jonathan Brassow 
Signed-off-by: Alasdair G Kergon

dm snapshot: lock snapshot while supplying status

2009-10-16T22:18:16+00:00

This patch locks the snapshot when returning status.  It fixes a race
when it could return an invalid number of free chunks if someone
was simultaneously modifying it.

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon

dm snapshot: require non zero chunk size by end of ctr

2009-10-16T22:18:16+00:00

If we are creating snapshot with memory-stored exception store, fail if
the user didn't specify chunk size. Zero chunk size would probably crash
a lot of places in the rest of snapshot code.

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Reviewed-by: Jonathan Brassow 
Reviewed-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon

dm snapshot: free exception store on init failure

2009-10-16T22:18:14+00:00

While initializing the snapshot module, if we fail to register
the snapshot target then we must back-out the exception store
module initialization.

Cc: stable@kernel.org
Signed-off-by: Jonathan Brassow 
Reviewed-by: Mikulas Patocka 
Reviewed-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon

dm snapshot: sort by chunk size to fix race

2009-10-16T22:18:14+00:00

Avoid a race causing corruption when snapshots of the same origin have
different chunk sizes by sorting the internal list of snapshots by chunk
size, largest first.
  https://bugzilla.redhat.com/show_bug.cgi?id=182659

For example, let's have two snapshots with different chunk sizes. The
first snapshot (1) has small chunk size and the second snapshot (2) has
large chunk size.  Let's have chunks A, B, C in these snapshots:
snapshot1: ====A====   ====B====
snapshot2: ==========C==========

(Chunk size is a power of 2. Chunks are aligned.)

A write to the origin at a position within A and C comes along. It
triggers reallocation of A, then reallocation of C and links them
together using A as the 'primary' exception.

Then another write to the origin comes along at a position within B and
C.  It creates pending exception for B.  C already has a reallocation in
progress and it already has a primary exception (A), so nothing is done
to it: B and C are not linked.

If the reallocation of B finishes before the reallocation of C, because
there is no link with the pending exception for C it does not know to
wait for it and, the second write is dispatched to the origin and causes
data corruption in the chunk C in snapshot2.

To avoid this situation, we maintain snapshots sorted in descending
order of chunk size.  This leads to a guaranteed ordering on the links
between the pending exceptions and avoids the problem explained above -
both A and B now get linked to C.

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon

dm snapshot: implement iterate devices

2009-09-04T19:40:19+00:00

Implement the .iterate_devices for the origin and snapshot targets.
dm-snapshot's lack of .iterate_devices resulted in the inability to
properly establish queue_limits for both targets.

With 4K sector drives: an unfortunate side-effect of not establishing
proper limits in either targets' DM device was that IO to the devices
would fail even though both had been created without error.

Commit af4874e03ed82f050d5872d8c39ce64bf16b5c38 ("dm target:s introduce
iterate devices fn") in 2.6.31-rc1 should have implemented .iterate_devices
for dm-snap.c's origin and snapshot targets.

Signed-off-by: Mike Snitzer 
Signed-off-by: Andrew Morton 
Signed-off-by: Alasdair G Kergon

dm snapshot: support barriers

2009-06-22T09:12:25+00:00

Flush support for dm-snapshot target.

This patch just forwards the flush request to either the origin or the snapshot
device.  (It doesn't flush exception store metadata.)

Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon

block: move bio list helpers into bio.h

2009-04-15T06:28:09+00:00

It's used by DM and MD and generally useful, so move the bio list
helpers into bio.h.

Signed-off-by: Christoph Hellwig 
Acked-by: Alasdair G Kergon 
Signed-off-by: Jens Axboe