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

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

dm log writes: move IO accounting earlier to fix error path

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

[ Upstream commit a5d60783df61fbb67b7596b8a0f6b4b2e05251d5 ]

Move log_one_block()'s atomic_inc(&lc->io_blocks) before bio_alloc() to
fix a bug that the target hangs if bio_alloc() fails.  The error path
does put_io_block(lc), so atomic_inc(&lc->io_blocks) must occur before
invoking the error path to avoid underflow of lc->io_blocks.

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

dm flakey: fix reads to be issued if drop_writes configured

2016-08-31T23:21:09+00:00

[ Upstream commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc ]

v4.8-rc3 commit 99f3c90d0d ("dm flakey: error READ bios during the
down_interval") overlooked the 'drop_writes' feature, which is meant to
allow reads to be issued rather than errored, during the down_interval.

Fixes: 99f3c90d0d ("dm flakey: error READ bios during the down_interval")
Reported-by: Qu Wenruo 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

bcache: RESERVE_PRIO is too small by one when prio_buckets() is a power of two.

2016-08-31T23:21:09+00:00

[ Upstream commit acc9cf8c66c66b2cbbdb4a375537edee72be64df ]

This patch fixes a cachedev registration-time allocation deadlock.
This can deadlock on boot if your initrd auto-registeres bcache devices:

Allocator thread:
[  720.727614] INFO: task bcache_allocato:3833 blocked for more than 120 seconds.
[  720.732361]  [] schedule+0x37/0x90
[  720.732963]  [] bch_bucket_alloc+0x188/0x360 [bcache]
[  720.733538]  [] ? prepare_to_wait_event+0xf0/0xf0
[  720.734137]  [] bch_prio_write+0x19d/0x340 [bcache]
[  720.734715]  [] bch_allocator_thread+0x3ff/0x470 [bcache]
[  720.735311]  [] ? __schedule+0x2dc/0x950
[  720.735884]  [] ? invalidate_buckets+0x980/0x980 [bcache]

Registration thread:
[  720.710403] INFO: task bash:3531 blocked for more than 120 seconds.
[  720.715226]  [] schedule+0x37/0x90
[  720.715805]  [] __bch_btree_map_nodes+0x12d/0x150 [bcache]
[  720.716409]  [] ? bch_btree_insert_check_key+0x1c0/0x1c0 [bcache]
[  720.717008]  [] bch_btree_insert+0xf4/0x170 [bcache]
[  720.717586]  [] ? prepare_to_wait_event+0xf0/0xf0
[  720.718191]  [] bch_journal_replay+0x14a/0x290 [bcache]
[  720.718766]  [] ? ttwu_do_activate.constprop.94+0x5d/0x70
[  720.719369]  [] ? try_to_wake_up+0x1d4/0x350
[  720.719968]  [] run_cache_set+0x580/0x8e0 [bcache]
[  720.720553]  [] register_bcache+0xe2e/0x13b0 [bcache]
[  720.721153]  [] kobj_attr_store+0xf/0x20
[  720.721730]  [] sysfs_kf_write+0x3d/0x50
[  720.722327]  [] kernfs_fop_write+0x12a/0x180
[  720.722904]  [] __vfs_write+0x37/0x110
[  720.723503]  [] ? __sb_start_write+0x58/0x110
[  720.724100]  [] ? security_file_permission+0x23/0xa0
[  720.724675]  [] vfs_write+0xa9/0x1b0
[  720.725275]  [] ? do_audit_syscall_entry+0x6c/0x70
[  720.725849]  [] SyS_write+0x55/0xd0
[  720.726451]  [] ? do_page_fault+0x30/0x80
[  720.727045]  [] system_call_fastpath+0x12/0x71

The fifo code in upstream bcache can't use the last element in the buffer,
which was the cause of the bug: if you asked for a power of two size,
it'd give you a fifo that could hold one less than what you asked for
rather than allocating a buffer twice as big.

Signed-off-by: Kent Overstreet 
Tested-by: Eric Wheeler 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

bcache: register_bcache(): call blkdev_put() when cache_alloc() fails

2016-08-31T23:21:09+00:00

[ Upstream commit d9dc1702b297ec4a6bb9c0326a70641b322ba886 ]

register_cache() is supposed to return an error string on error so that
register_bcache() will will blkdev_put and cleanup other user counters,
but it does not set 'char *err' when cache_alloc() fails (eg, due to
memory pressure) and thus register_bcache() performs no cleanup.

register_bcache() <----------\  <- no jump to err_close, no blkdev_put()
   |                         |
   +->register_cache()       |  <- fails to set char *err
         |                   |
         +->cache_alloc() ---/  <- returns error

This patch sets `char *err` for this failure case so that register_cache()
will cause register_bcache() to correctly jump to err_close and do
cleanup.  This was tested under OOM conditions that triggered the bug.

Signed-off-by: Eric Wheeler 
Cc: Kent Overstreet 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

dm: set DMF_SUSPENDED* _before_ clearing DMF_NOFLUSH_SUSPENDING

2016-08-20T03:08:33+00:00

[ Upstream commit eaf9a7361f47727b166688a9f2096854eef60fbe ]

Otherwise, there is potential for both DMF_SUSPENDED* and
DMF_NOFLUSH_SUSPENDING to not be set during dm_suspend() -- which is
definitely _not_ a valid state.

This fix, in conjuction with "dm rq: fix the starting and stopping of
blk-mq queues", addresses the potential for request-based DM multipath's
__multipath_map() to see !dm_noflush_suspending() during suspend.

Reported-by: Bart Van Assche 
Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

dm rq: fix the starting and stopping of blk-mq queues

2016-08-20T03:08:32+00:00

[ Upstream commit 7d9595d848cdff5c7939f68eec39e0c5d36a1d67 ]

Improve dm_stop_queue() to cancel any requeue_work.  Also, have
dm_start_queue() and dm_stop_queue() clear/set the QUEUE_FLAG_STOPPED
for the blk-mq request_queue.

On suspend dm_stop_queue() handles stopping the blk-mq request_queue
BUT: even though the hw_queues are marked BLK_MQ_S_STOPPED at that point
there is still a race that is allowing block/blk-mq.c to call ->queue_rq
against a hctx that it really shouldn't.  Add a check to
dm_mq_queue_rq() that guards against this rarity (albeit _not_
race-free).

Signed-off-by: Mike Snitzer 
Cc: stable@vger.kernel.org # must patch dm.c on < 4.8 kernels
Signed-off-by: Sasha Levin