2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-06 03:04:54 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-19 22:38:44 +01:00
|
|
|
|
2008-04-24 22:02:01 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
2009-01-06 03:05:15 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-26 00:27:35 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
2015-06-21 16:31:33 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-06 02:32:33 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-06 02:32:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-06 02:32:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-01 22:45:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-12 04:13:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-06 20:33:20 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2012-12-21 20:23:38 +00:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:33 +00:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:33 +00:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
2008-07-21 12:00:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-30 13:33:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-30 13:33:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-30 13:33:12 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-13 19:13:36 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-01-13 19:13:36 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-30 13:33:16 +00:00
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-30 13:33:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-17 18:06:10 +01:00
|
|
|
|
2008-10-30 13:33:16 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-06 03:05:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-06 03:05:19 +00:00
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-01-13 19:13:36 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:08 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-09-18 19:40:42 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-09-18 19:40:42 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:51:54 +00:00
|
|
|
|
|
|
|
|
|
2008-02-08 02:10:06 +00:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-17 18:06:10 +01:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sched: Remove proliferation of wait_on_bit() action functions
The current "wait_on_bit" interface requires an 'action'
function to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().
So:
Rename wait_on_bit and wait_on_bit_lock to
wait_on_bit_action and wait_on_bit_lock_action
to make it explicit that they need an action function.
Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
which are *not* given an action function but implicitly use
a standard one.
The decision to error-out if a signal is pending is now made
based on the 'mode' argument rather than being encoded in the action
function.
All instances of the old wait_on_bit and wait_on_bit_lock which
can use the new version have been changed accordingly and their
action functions have been discarded.
wait_on_bit{_lock} does not return any specific error code in the
event of a signal so the caller must check for non-zero and
interpolate their own error code as appropriate.
The wait_on_bit() call in __fscache_wait_on_invalidate() was
ambiguous as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
David Howells confirms this should be uniformly
"uninterruptible"
The main remaining user of wait_on_bit{,_lock}_action is NFS
which needs to use a freezer-aware schedule() call.
A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan'
field of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they
will not show up at all, but something higher in the stack. So
the distinction will still be visible, only with different
function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
gfs2/glock.c case).
Since first version of this patch (against 3.15) two new action
functions appeared, on in NFS and one in CIFS. CIFS also now
uses an action function that makes the same freezer aware
schedule call as NFS.
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: David Howells <dhowells@redhat.com> (fscache, keys)
Acked-by: Steven Whitehouse <swhiteho@redhat.com> (gfs2)
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steve French <sfrench@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brown
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-07-07 15:16:04 +10:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-08 18:05:41 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2016-02-02 12:29:18 +08:00
|
|
|
|
2013-03-01 22:45:47 +00:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-03 01:15:25 -07:00
|
|
|
|
2006-06-26 00:27:35 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2013-03-01 22:45:47 +00:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:03 +01:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-12 04:13:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-02 12:29:18 +08:00
|
|
|
|
2010-08-12 04:13:51 +01:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-02 12:29:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-24 13:52:14 +00:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-06-21 16:31:33 -04:00
|
|
|
|
2006-02-01 03:04:50 -08:00
|
|
|
|
2008-10-30 13:33:16 +00:00
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2006-10-03 01:15:30 -07:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-01 22:45:49 +00:00
|
|
|
|
2011-05-29 13:03:13 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-10 14:37:15 +01:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2013-03-01 22:45:47 +00:00
|
|
|
|
2016-01-31 13:28:26 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:31 +01:00
|
|
|
|
|
|
|
|
|
2007-07-12 17:28:13 +01:00
|
|
|
|
2006-10-03 01:15:25 -07:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2007-07-12 17:28:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:25 -07:00
|
|
|
|
2006-02-01 03:04:50 -08:00
|
|
|
|
2009-10-16 23:18:16 +01:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2008-04-24 21:43:19 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2010-08-12 04:13:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:41:11 -08:00
|
|
|
|
|
|
|
|
|
2008-04-24 21:43:19 +01:00
|
|
|
|
2006-12-08 02:41:11 -08:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
2006-12-08 02:41:11 -08:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 18:05:41 -04:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2015-06-21 16:31:33 -04:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:50 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-30 13:33:16 +00:00
|
|
|
|
2009-01-06 03:04:54 +00:00
|
|
|
|
2008-10-30 13:33:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:41:11 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-21 12:00:35 +01:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2006-03-27 01:17:50 -08:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
|
|
|
|
|
2010-08-12 04:13:51 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-27 12:47:43 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:31 -07:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:31 +01:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
2016-01-08 19:07:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-08 19:07:55 -05:00
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-10-03 01:15:31 -07:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-13 19:13:36 -05:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-10-03 01:15:31 -07:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:29 +00:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:34 +01:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2011-08-02 12:32:03 +01:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2015-11-25 16:03:31 -05:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
|
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2006-10-03 01:15:29 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2015-02-17 14:34:00 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-08 19:07:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-28 14:16:10 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-24 21:43:17 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:33 +01:00
|
|
|
|
2009-10-16 23:18:17 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2009-04-02 19:55:33 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:03 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2009-04-02 19:55:31 +01:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dm snapshot: avoid snapshot space leak on crash
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2013-11-29 18:13:37 -05:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2006-12-08 02:41:06 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
|
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2009-06-22 10:12:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-03 09:38:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:02 +02:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2015-06-21 16:31:33 -04:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2017-06-03 09:38:02 +02:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2009-04-02 19:55:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2015-10-08 18:05:41 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:02 +02:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-08 02:11:27 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2006-12-08 02:41:06 -08:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2011-08-02 12:32:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2006-10-03 01:15:28 -07:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-08-02 12:32:03 +01:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2011-08-02 12:32:03 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
|
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2013-03-01 22:45:47 +00:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2009-12-10 23:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2009-12-10 23:52:33 +00:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:36 +00:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2017-06-03 09:38:03 +02:00
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-13 19:59:59 +00:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
dm snapshot: suspend merging snapshot when doing exception handover
The "dm snapshot: suspend origin when doing exception handover" commit
fixed a exception store handover bug associated with pending exceptions
to the "snapshot-origin" target.
However, a similar problem exists in snapshot merging. When snapshot
merging is in progress, we use the target "snapshot-merge" instead of
"snapshot-origin". Consequently, during exception store handover, we
must find the snapshot-merge target and suspend its associated
mapped_device.
To avoid lockdep warnings, the target must be suspended and resumed
without holding _origins_lock.
Introduce a dm_hold() function that grabs a reference on a
mapped_device, but unlike dm_get(), it doesn't crash if the device has
the DMF_FREEING flag set, it returns an error in this case.
In snapshot_resume() we grab the reference to the origin device using
dm_hold() while holding _origins_lock (_origins_lock guarantees that the
device won't disappear). Then we release _origins_lock, suspend the
device and grab _origins_lock again.
NOTE to stable@ people:
When backporting to kernels 3.18 and older, use dm_internal_suspend and
dm_internal_resume instead of dm_internal_suspend_fast and
dm_internal_resume_fast.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
2015-02-26 11:41:28 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-02-01 03:04:50 -08:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-01 22:45:44 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:51:53 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:51:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2009-12-10 23:52:35 +00:00
|
|
|
|
|
|
|
|
|
2015-06-21 16:31:33 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:51:53 +00:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-12-10 23:51:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:12 +00:00
|
|
|
|
2009-04-02 19:55:35 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-12 04:13:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
2010-08-12 04:13:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2006-02-01 03:04:50 -08:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-07-12 15:53:05 -07:00
|
|
|
|
2009-12-10 23:52:28 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:28 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:11 +00:00
|
|
|
|
2009-04-02 19:55:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
2009-04-02 19:55:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-08-02 12:32:03 +01:00
|
|
|
|
2017-11-23 16:15:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:17:44 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 02:41:06 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2009-12-10 23:52:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:35 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2013-03-01 22:45:47 +00:00
|
|
|
|
2009-06-22 10:12:25 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-12-21 20:23:41 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2014-03-14 18:43:07 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2009-06-22 10:12:25 +01:00
|
|
|
|
|
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2009-06-22 10:12:25 +01:00
|
|
|
|
|
|
|
|
|
2014-03-14 18:43:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-14 18:43:07 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-12 13:37:44 -07:00
|
|
|
|
|
|
|
|
|
2016-06-28 13:37:16 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-27 15:08:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-14 18:43:07 -04:00
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-01 22:45:44 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
2014-03-14 18:42:12 -04:00
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 11:40:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
2017-04-12 13:37:44 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 18:05:41 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 12:00:32 +01:00
|
|
|
|
2009-12-10 23:52:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-09-04 20:40:19 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
2015-10-08 18:05:41 -04:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:31 +00:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2009-12-10 23:52:32 +00:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-06 03:05:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-07-12 17:26:32 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-11-25 01:43:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-10-16 23:18:14 +01:00
|
|
|
|
2017-11-25 01:43:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-16 23:18:14 +01:00
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-06 03:04:58 +00:00
|
|
|
|
|
|
|
|
|
2009-12-10 23:52:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-06 03:05:17 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-01 22:45:47 +00:00
|
|
|
|
|
|
|
|
|