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

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

2016-09-15T06:20:28+00:00

commit acc9cf8c66c66b2cbbdb4a375537edee72be64df upstream.

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 
Signed-off-by: Greg Kroah-Hartman

dm round robin: do not use this_cpu_ptr() without having preemption disabled

2016-09-07T06:34:52+00:00

commit 802934b2cfde463b72cc1b9bc1c081895a90be53 upstream.

Use local_irq_save() to disable preemption before calling
this_cpu_ptr().

Reported-by: Benjamin Block 
Fixes: b0b477c7e0dd ("dm round robin: use percpu 'repeat_count' and 'current_path'")
Suggested-by: Jens Axboe 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dm flakey: error READ bios during the down_interval

2016-08-20T16:11:04+00:00

commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 upstream.

When the corrupt_bio_byte feature was introduced it caused READ bios to
no longer be errored with -EIO during the down_interval.  This had to do
with the complexity of needing to submit READs if the corrupt_bio_byte
feature was used.

Fix it so READ bios are properly errored with -EIO; doing so early in
flakey_map() as long as there isn't a match for the corrupt_bio_byte
feature.

Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
Reported-by: Akira Hayakawa 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dm verity fec: fix block calculation

2016-08-20T16:10:53+00:00

commit 602d1657c603eedd7379a8bcde1ad3a2972ecc5f upstream.

do_div was replaced with div64_u64 at some point, causing a bug with
block calculation due to incompatible semantics of the two functions.

Signed-off-by: Sami Tolvanen 
Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dm: set DMF_SUSPENDED* _before_ clearing DMF_NOFLUSH_SUSPENDING

2016-08-20T16:10:52+00:00

commit eaf9a7361f47727b166688a9f2096854eef60fbe upstream.

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 
Signed-off-by: Greg Kroah-Hartman

dm: fix second blk_delay_queue() parameter to be in msec units not jiffies

2016-08-20T16:10:52+00:00

commit bd9f55ea1cf6e14eb054b06ea877d2d1fa339514 upstream.

Commit d548b34b062 ("dm: reduce the queue delay used in dm_request_fn
from 100ms to 10ms") always intended the value to be 10 msecs -- it
just expressed it in jiffies because earlier commit 7eaceaccab ("block:
remove per-queue plugging") did.

Signed-off-by: Tahsin Erdogan 
Signed-off-by: Mike Snitzer 
Fixes: d548b34b062 ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms")
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

2016-05-27T21:28:09+00:00

Pull block fixes from Jens Axboe:
 "A set of fixes that wasn't included in the first merge window pull
  request.  This pull request contains:

   - A set of NVMe fixes from Keith, and one from Nic for the integrity
     side of it.

   - Fix from Ming, clearing ->mq_ops if we don't successfully setup a
     queue for multiqueue.

   - A set of stability fixes for bcache from Jiri, and also marking
     bcache as orphaned as it's no longer actively maintained (in
     mainline, at least)"

* 'for-linus' of git://git.kernel.dk/linux-block:
  blk-mq: clear q->mq_ops if init fail
  MAINTAINERS: mark bcache as orphan
  bcache: bch_gc_thread() is not freezable
  bcache: bch_allocator_thread() is not freezable
  bcache: bch_writeback_thread() is not freezable
  nvme/host: Add missing blk_integrity tag_size + flags assignments
  NVMe: Add device ID's with stripe quirk
  NVMe: Short-cut removal on surprise hot-unplug
  NVMe: Allow user initiated rescan
  NVMe: Reduce driver log spamming
  NVMe: Unbind driver on failure
  NVMe: Delete only created queues
  NVMe: Allocate queues only for online cpus

bcache: bch_gc_thread() is not freezable

2016-05-24T15:00:45+00:00

bch_gc_thread() doesn't mark itself freezable, so calling try_to_freeze()
in its context is just an expensive no-op.

Signed-off-by: Jiri Kosina 
Signed-off-by: Jens Axboe

bcache: bch_allocator_thread() is not freezable

2016-05-24T15:00:43+00:00

bch_allocator_thread() is calling try_to_freeze(), but that's just an
expensive no-op given the fact that the thread is not marked freezable.

Bucket allocator has to be up and running to the very last stages of the
suspend, as the bcache I/O that's in flight (think of writing an
hibernation image to a swap device served by bcache).

Signed-off-by: Jiri Kosina 
Signed-off-by: Jens Axboe

bcache: bch_writeback_thread() is not freezable

2016-05-24T15:00:40+00:00

bch_writeback_thread() is calling try_to_freeze(), but that's just an
expensive no-op given the fact that the thread is not marked freezable.

I/O helper kthreads, exactly such as the bcache writeback thread, actually
shouldn't be freezable, because they are potentially necessary for
finalizing the image write-out.

Signed-off-by: Jiri Kosina 
Signed-off-by: Jens Axboe