litmus-rt.git/drivers/md/bcache, branch test The LITMUS^RT kernel. md/bcache: use generic io stats accounting functions to simplify io stat accounting 2014-11-24T15:05:12+00:00 Gu Zheng guz.fnst@cn.fujitsu.com 2014-11-24T03:05:24+00:00 aae4933da9488827d341c31b970b2f62ac45a496 Use generic io stats accounting help functions (generic_{start,end}_io_acct) to simplify io stat accounting. Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Acked-by: Kent Overstreet <kmo@datera.io> Signed-off-by: Jens Axboe <axboe@fb.com> 
Use generic io stats accounting help functions (generic_{start,end}_io_acct)
to simplify io stat accounting.

Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Acked-by: Kent Overstreet <kmo@datera.io>
Signed-off-by: Jens Axboe <axboe@fb.com>
block: disable entropy contributions for nonrot devices 2014-10-04T16:55:32+00:00 Mike Snitzer snitzer@redhat.com 2014-10-04T16:55:32+00:00 b277da0a8a594308e17881f4926879bd5fca2a2d Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set QUEUE_FLAG_NONROT. Historically, all block devices have automatically made entropy contributions. But as previously stated in commit e2e1a148 ("block: add sysfs knob for turning off disk entropy contributions"): - On SSD disks, the completion times aren't as random as they are for rotational drives. So it's questionable whether they should contribute to the random pool in the first place. - Calling add_disk_randomness() has a lot of overhead. There are more reliable sources for randomness than non-rotational block devices. From a security perspective it is better to err on the side of caution than to allow entropy contributions from unreliable "random" sources. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com> 
Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
QUEUE_FLAG_NONROT.

Historically, all block devices have automatically made entropy
contributions.  But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
    - On SSD disks, the completion times aren't as random as they
      are for rotational drives. So it's questionable whether they
      should contribute to the random pool in the first place.
    - Calling add_disk_randomness() has a lot of overhead.

There are more reliable sources for randomness than non-rotational block
devices.  From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
bcache: Drop unneeded blk_sync_queue() calls 2014-08-04T22:23:04+00:00 Kent Overstreet kmo@daterainc.com 2014-07-07T20:03:36+00:00 0781c8748cf1ea2b0dcd966571103909528c4efa this is needed for the queue/block device we created (it's done by blk_cleanup_queue() which we do call) - but calling it for the block devices we only opened is pointless. Change-Id: I53dfded14ed15b9581d10ca8399d5e1b3abbf9f2 
this is needed for the queue/block device we created (it's done by
blk_cleanup_queue() which we do call) - but calling it for the block devices we
only opened is pointless.

Change-Id: I53dfded14ed15b9581d10ca8399d5e1b3abbf9f2
bcache: add mutex lock for bch_is_open 2014-08-04T22:23:04+00:00 Jianjian Huo samuel.huo@gmail.com 2014-07-13T16:08:59+00:00 789d21dbd9d8889e62c79ec19585fcc97e42ef07 Since bch_is_open will iterate linked list bch_cache_sets and uncached_devices, it needs bch_register_lock. Signed-off-by: Jianjian Huo <samuel.huo@gmail.com> 
Since bch_is_open will iterate linked list bch_cache_sets and
uncached_devices, it needs bch_register_lock.

Signed-off-by: Jianjian Huo <samuel.huo@gmail.com>
bcache: Correct printing of btree_gc_max_duration_ms 2014-08-04T22:23:04+00:00 Surbhi Palande sap@daterainc.com 2014-04-17T19:07:04+00:00 5b25abade29616d42d60f9bd5e6a5ad07f7314e3 time_stats::btree_gc_max_duration_mc is not bit shifted by 8 Fixes BUG #138 Change-Id: I44fc6e1d0579674016acc533f1a546b080e5371a Signed-off-by: Surbhi Palande <sap@daterainc.com> 
time_stats::btree_gc_max_duration_mc is not bit shifted by 8

Fixes BUG #138

Change-Id: I44fc6e1d0579674016acc533f1a546b080e5371a
Signed-off-by: Surbhi Palande <sap@daterainc.com>
bcache: try to set b->parent properly 2014-08-04T22:23:04+00:00 Slava Pestov sp@daterainc.com 2014-07-12T07:22:53+00:00 2452cc89063a2a6890368f185c4b6d7d8802179e bcache_flash_dev.ktest would reliably crash with 8k and 16k bucket size before; now it passes. Change-Id: Ib542232235e39298c3a7548fe52b645cabb823d1 
bcache_flash_dev.ktest would reliably crash with 8k and 16k bucket size
before; now it passes.

Change-Id: Ib542232235e39298c3a7548fe52b645cabb823d1
bcache: fix memory corruption in init error path 2014-08-04T22:23:04+00:00 Slava Pestov sp@daterainc.com 2014-06-19T22:05:59+00:00 c9a78332b42cbdcdd386a95192a716b67d1711a4 If register_cache_set() failed, we would touch ca->set after it had already been freed. Also, fix an assertion to catch this. Change-Id: I748e5f5b223e2d9b2602075dec2f997cced2394d 
If register_cache_set() failed, we would touch ca->set after
it had already been freed. Also, fix an assertion to catch
this.

Change-Id: I748e5f5b223e2d9b2602075dec2f997cced2394d
bcache: fix crash with incomplete cache set 2014-08-04T22:23:04+00:00 Slava Pestov sp@daterainc.com 2014-07-11T19:17:41+00:00 bf0c55c986540483c34ca640f2eef4c3314388b1 Change-Id: I6abde52afe917633480caaf4e2518f42a816d886 
Change-Id: I6abde52afe917633480caaf4e2518f42a816d886
bcache: Fix more early shutdown bugs 2014-08-04T22:23:04+00:00 Kent Overstreet kmo@daterainc.com 2014-06-12T02:44:49+00:00 d83353b319d47ef8cce82467da6a25c2d558253f Signed-off-by: Kent Overstreet <kmo@daterainc.com> 
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
bcache: fix use-after-free in btree_gc_coalesce() 2014-08-04T22:23:04+00:00 Slava Pestov sp@daterainc.com 2014-07-13T04:53:11+00:00 400ffaa2acd72274e2c7293a9724382383bebf3e If we goto out_nocoalesce after we free new_nodes[0], we end up freeing new_nodes[0] again. This was generating a lockdep warning. The fix is to set new_nodes[0] to NULL, since the out_nocoalesce path safely ignores NULL entries in the new_nodes array. This regression was introduced in 2d7f9531. Change-Id: I76564d7257800583214376b4bacf236cda90c89c 
If we goto out_nocoalesce after we free new_nodes[0], we end up freeing
new_nodes[0] again. This was generating a lockdep warning. The fix is
to set new_nodes[0] to NULL, since the out_nocoalesce path safely
ignores NULL entries in the new_nodes array.

This regression was introduced in 2d7f9531.

Change-Id: I76564d7257800583214376b4bacf236cda90c89c