linux-stable.git/drivers/md, branch v4.1.38

dm space map metadata: fix 'struct sm_metadata' leak on failed create

2017-01-13T01:56:56+00:00

[ Upstream commit 314c25c56c1ee5026cf99c570bdfe01847927acb ]

In dm_sm_metadata_create() we temporarily change the dm_space_map
operations from 'ops' (whose .destroy function deallocates the
sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't).

If dm_sm_metadata_create() fails in sm_ll_new_metadata() or
sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls
dm_sm_destroy() with the intention of freeing the sm_metadata, but it
doesn't (because the dm_space_map operations is still set to
'bootstrap_ops').

Fix this by setting the dm_space_map operations back to 'ops' if
dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'.

Signed-off-by: Benjamin Marzinski 
Acked-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

md/raid5: limit request size according to implementation limits

2017-01-13T01:56:54+00:00

[ Upstream commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 ]

Current implementation employ 16bit counter of active stripes in lower
bits of bio->bi_phys_segments. If request is big enough to overflow
this counter bio will be completed and freed too early.

Fortunately this not happens in default configuration because several
other limits prevent that: stripe_cache_size * nr_disks effectively
limits count of active stripes. And small max_sectors_kb at lower
disks prevent that during normal read/write operations.

Overflow easily happens in discard if it's enabled by module parameter
"devices_handle_discard_safely" and stripe_cache_size is set big enough.

This patch limits requests size with 256Mb - 8Kb to prevent overflows.

Signed-off-by: Konstantin Khlebnikov 
Cc: Shaohua Li 
Cc: Neil Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

dm crypt: mark key as invalid until properly loaded

2017-01-13T01:56:54+00:00

[ Upstream commit 265e9098bac02bc5e36cda21fdbad34cb5b2f48d ]

In crypt_set_key(), if a failure occurs while replacing the old key
(e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag
set.  Otherwise, the crypto layer would have an invalid key that still
has DM_CRYPT_KEY_VALID flag set.

Cc: stable@vger.kernel.org
Signed-off-by: Ondrej Kozina 
Reviewed-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

md: be careful not lot leak internal curr_resync value into metadata. -- (all)

2016-11-26T03:57:03+00:00

[ Upstream commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 ]

mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.

 1 - means that the array is trying to start a resync, but has yielded
     to another array which shares physical devices, and also needs to
     start a resync
 2 - means the array is trying to start resync, but has found another
     array which shares physical devices and has already started resync.

 3 - means that resync has commensed, but it is possible that nothing
     has actually been resynced yet.

It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint.  In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.

There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.

Change them to only propagate the value if it is > 3.

As this can cause an array to fail, the patch is suitable for -stable.

Cc: stable@vger.kernel.org (v3.7+)
Reported-by: Viswesh 
Signed-off-by: NeilBrown 
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

md: sync sync_completed has correct value as recovery finishes.

2016-11-26T03:57:03+00:00

[ Upstream commit 5ed1df2eacc0ba92c8c7e2499c97594b5ef928a8 ]

There can be a small window between the moment that recovery
actually writes the last block and the time when various sysfs
and /proc/mdstat attributes report that it has finished.
During this time, 'sync_completed' can have the wrong value.
This can confuse monitoring software.

So:
 - don't set curr_resync_completed beyond the end of the devices,
 - set it correctly when resync/recovery has completed.

Signed-off-by: NeilBrown 
Signed-off-by: Sasha Levin

dm table: fix missing dm_put_target_type() in dm_table_add_target()

2016-11-24T01:59:49+00:00

[ Upstream commit dafa724bf582181d9a7d54f5cb4ca0bf8ef29269 ]

dm_get_target_type() was previously called so any error returned from
dm_table_add_target() must first call dm_put_target_type().  Otherwise
the DM target module's reference count will leak and the associated
kernel module will be unable to be removed.

Also, leverage the fact that r is already -EINVAL and remove an extra
newline.

Fixes: 36a0456 ("dm table: add immutable feature")
Fixes: cc6cbe1 ("dm table: add always writeable feature")
Fixes: 3791e2f ("dm table: add singleton feature")
Cc: stable@vger.kernel.org # 3.2+
Signed-off-by: tang.junhui 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

dm crypt: fix free of bad values after tfm allocation failure

2016-09-15T22:53:30+00:00

[ Upstream commit 5d0be84ec0cacfc7a6d6ea548afdd07d481324cd ]

If crypt_alloc_tfms() had to allocate multiple tfms and it failed before
the last allocation, then it would call crypt_free_tfms() and could free
pointers from uninitialized memory -- due to the crypt_free_tfms() check
for non-zero cc->tfms[i].  Fix by allocating zeroed memory.

Signed-off-by: Eric Biggers 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

dm crypt: fix error with too large bios

2016-09-15T22:53:30+00:00

[ Upstream commit 4e870e948fbabf62b78e8410f04c67703e7c816b ]

When dm-crypt processes writes, it allocates a new bio in
crypt_alloc_buffer().  The bio is allocated from a bio set and it can
have at most BIO_MAX_PAGES vector entries, however the incoming bio can be
larger (e.g. if it was allocated by bcache).  If the incoming bio is
larger, bio_alloc_bioset() fails and an error is returned.

To avoid the error, we test for a too large bio in the function
crypt_map() and use dm_accept_partial_bio() to split the bio.
dm_accept_partial_bio() trims the current bio to the desired size and
asks DM core to send another bio with the rest of the data.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org # v3.16+
Signed-off-by: Sasha Levin

dm log writes: fix check of kthread_run() return value

2016-09-15T22:53:30+00:00

[ Upstream commit 91e630d9ae6de6f740ef7c8176736eb55366833e ]

The kthread_run() function returns either a valid task_struct or
ERR_PTR() value, check for NULL is invalid.  This change fixes potential
for oops, e.g. in OOM situation.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

dm log writes: fix bug with too large bios

2016-09-15T22:53:30+00:00

[ Upstream commit 7efb367320f56fc4d549875b6f3a6940018ef2e5 ]

bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector
entries.  However, the incoming bio may have more vector entries if it
was allocated by other means.  For example, bcache submits bios with
more than BIO_MAX_PAGES entries.  This results in bio_alloc() failure.

To avoid the failure, change the code so that it allocates bio with at
most BIO_MAX_PAGES entries.  If the incoming bio has more entries,
bio_add_page() will fail and a new bio will be allocated - the code that
handles bio_add_page() failure already exists in the dm-log-writes
target.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Josef Bacik 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Sasha Levin