* [PATCH 8/9] virtio_blk: use virtio IRQ affinity
From: Christoph Hellwig @ 2017-02-05 17:15 UTC (permalink / raw)
To: mst, jasowang; +Cc: axboe, pbonzini, virtualization, linux-block, linux-kernel
In-Reply-To: <20170205171526.6224-1-hch@lst.de>
Use automatic IRQ affinity assignment in the virtio layer if available,
and build the blk-mq queues based on it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/virtio_blk.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index c54118bdc67d..1028dfeb5a7f 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -5,6 +5,7 @@
#include <linux/hdreg.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/interrupt.h>
#include <linux/virtio.h>
#include <linux/virtio_blk.h>
#include <linux/scatterlist.h>
@@ -12,6 +13,7 @@
#include <scsi/scsi_cmnd.h>
#include <linux/idr.h>
#include <linux/blk-mq.h>
+#include <linux/blk-mq-virtio.h>
#include <linux/numa.h>
#define PART_BITS 4
@@ -385,6 +387,7 @@ static int init_vq(struct virtio_blk *vblk)
struct virtqueue **vqs;
unsigned short num_vqs;
struct virtio_device *vdev = vblk->vdev;
+ struct irq_affinity desc = { 0, };
err = virtio_cread_feature(vdev, VIRTIO_BLK_F_MQ,
struct virtio_blk_config, num_queues,
@@ -412,7 +415,7 @@ static int init_vq(struct virtio_blk *vblk)
/* Discover virtqueues and write information to configuration. */
err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names,
- NULL);
+ &desc);
if (err)
goto out;
@@ -543,10 +546,18 @@ static int virtblk_init_request(void *data, struct request *rq,
return 0;
}
+static int virtblk_map_queues(struct blk_mq_tag_set *set)
+{
+ struct virtio_blk *vblk = set->driver_data;
+
+ return blk_mq_virtio_map_queues(set, vblk->vdev, 0);
+}
+
static struct blk_mq_ops virtio_mq_ops = {
.queue_rq = virtio_queue_rq,
.complete = virtblk_request_done,
.init_request = virtblk_init_request,
+ .map_queues = virtblk_map_queues,
};
static unsigned int virtblk_queue_depth;
--
2.11.0
^ permalink raw reply related
* [PATCH 9/9] virtio_scsi: use virtio IRQ affinity
From: Christoph Hellwig @ 2017-02-05 17:15 UTC (permalink / raw)
To: mst, jasowang; +Cc: axboe, pbonzini, virtualization, linux-block, linux-kernel
In-Reply-To: <20170205171526.6224-1-hch@lst.de>
Use automatic IRQ affinity assignment in the virtio layer if available,
and build the blk-mq queues based on it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/scsi/virtio_scsi.c | 126 +++++----------------------------------------
include/linux/cpuhotplug.h | 1 -
2 files changed, 12 insertions(+), 115 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 32a16293436b..5582c8baeabb 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/mempool.h>
+#include <linux/interrupt.h>
#include <linux/virtio.h>
#include <linux/virtio_ids.h>
#include <linux/virtio_config.h>
@@ -29,6 +30,7 @@
#include <scsi/scsi_cmnd.h>
#include <scsi/scsi_tcq.h>
#include <linux/seqlock.h>
+#include <linux/blk-mq-virtio.h>
#define VIRTIO_SCSI_MEMPOOL_SZ 64
#define VIRTIO_SCSI_EVENT_LEN 8
@@ -108,7 +110,6 @@ struct virtio_scsi {
bool affinity_hint_set;
struct hlist_node node;
- struct hlist_node node_dead;
/* Protected by event_vq lock */
bool stop_events;
@@ -118,7 +119,6 @@ struct virtio_scsi {
struct virtio_scsi_vq req_vqs[];
};
-static enum cpuhp_state virtioscsi_online;
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
@@ -757,6 +757,13 @@ static void virtscsi_target_destroy(struct scsi_target *starget)
kfree(tgt);
}
+static int virtscsi_map_queues(struct Scsi_Host *shost)
+{
+ struct virtio_scsi *vscsi = shost_priv(shost);
+
+ return blk_mq_virtio_map_queues(&shost->tag_set, vscsi->vdev, 2);
+}
+
static struct scsi_host_template virtscsi_host_template_single = {
.module = THIS_MODULE,
.name = "Virtio SCSI HBA",
@@ -792,6 +799,7 @@ static struct scsi_host_template virtscsi_host_template_multi = {
.use_clustering = ENABLE_CLUSTERING,
.target_alloc = virtscsi_target_alloc,
.target_destroy = virtscsi_target_destroy,
+ .map_queues = virtscsi_map_queues,
.track_queue_depth = 1,
};
@@ -808,80 +816,6 @@ static struct scsi_host_template virtscsi_host_template_multi = {
virtio_cwrite(vdev, struct virtio_scsi_config, fld, &__val); \
} while(0)
-static void __virtscsi_set_affinity(struct virtio_scsi *vscsi, bool affinity)
-{
- int i;
- int cpu;
-
- /* In multiqueue mode, when the number of cpu is equal
- * to the number of request queues, we let the qeueues
- * to be private to one cpu by setting the affinity hint
- * to eliminate the contention.
- */
- if ((vscsi->num_queues == 1 ||
- vscsi->num_queues != num_online_cpus()) && affinity) {
- if (vscsi->affinity_hint_set)
- affinity = false;
- else
- return;
- }
-
- if (affinity) {
- i = 0;
- for_each_online_cpu(cpu) {
- virtqueue_set_affinity(vscsi->req_vqs[i].vq, cpu);
- i++;
- }
-
- vscsi->affinity_hint_set = true;
- } else {
- for (i = 0; i < vscsi->num_queues; i++) {
- if (!vscsi->req_vqs[i].vq)
- continue;
-
- virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
- }
-
- vscsi->affinity_hint_set = false;
- }
-}
-
-static void virtscsi_set_affinity(struct virtio_scsi *vscsi, bool affinity)
-{
- get_online_cpus();
- __virtscsi_set_affinity(vscsi, affinity);
- put_online_cpus();
-}
-
-static int virtscsi_cpu_online(unsigned int cpu, struct hlist_node *node)
-{
- struct virtio_scsi *vscsi = hlist_entry_safe(node, struct virtio_scsi,
- node);
- __virtscsi_set_affinity(vscsi, true);
- return 0;
-}
-
-static int virtscsi_cpu_notif_add(struct virtio_scsi *vi)
-{
- int ret;
-
- ret = cpuhp_state_add_instance(virtioscsi_online, &vi->node);
- if (ret)
- return ret;
-
- ret = cpuhp_state_add_instance(CPUHP_VIRT_SCSI_DEAD, &vi->node_dead);
- if (ret)
- cpuhp_state_remove_instance(virtioscsi_online, &vi->node);
- return ret;
-}
-
-static void virtscsi_cpu_notif_remove(struct virtio_scsi *vi)
-{
- cpuhp_state_remove_instance_nocalls(virtioscsi_online, &vi->node);
- cpuhp_state_remove_instance_nocalls(CPUHP_VIRT_SCSI_DEAD,
- &vi->node_dead);
-}
-
static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
struct virtqueue *vq)
{
@@ -891,14 +825,8 @@ static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
static void virtscsi_remove_vqs(struct virtio_device *vdev)
{
- struct Scsi_Host *sh = virtio_scsi_host(vdev);
- struct virtio_scsi *vscsi = shost_priv(sh);
-
- virtscsi_set_affinity(vscsi, false);
-
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
-
vdev->config->del_vqs(vdev);
}
@@ -911,6 +839,7 @@ static int virtscsi_init(struct virtio_device *vdev,
vq_callback_t **callbacks;
const char **names;
struct virtqueue **vqs;
+ struct irq_affinity desc = { .pre_vectors = 2 };
num_vqs = vscsi->num_queues + VIRTIO_SCSI_VQ_BASE;
vqs = kmalloc(num_vqs * sizeof(struct virtqueue *), GFP_KERNEL);
@@ -933,7 +862,7 @@ static int virtscsi_init(struct virtio_device *vdev,
/* Discover virtqueues and write information to configuration. */
err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names,
- NULL);
+ &desc);
if (err)
goto out;
@@ -999,10 +928,6 @@ static int virtscsi_probe(struct virtio_device *vdev)
if (err)
goto virtscsi_init_failed;
- err = virtscsi_cpu_notif_add(vscsi);
- if (err)
- goto scsi_add_host_failed;
-
cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1;
shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
shost->max_sectors = virtscsi_config_get(vdev, max_sectors) ?: 0xFFFF;
@@ -1057,9 +982,6 @@ static void virtscsi_remove(struct virtio_device *vdev)
virtscsi_cancel_event_work(vscsi);
scsi_remove_host(shost);
-
- virtscsi_cpu_notif_remove(vscsi);
-
virtscsi_remove_vqs(vdev);
scsi_host_put(shost);
}
@@ -1067,10 +989,6 @@ static void virtscsi_remove(struct virtio_device *vdev)
#ifdef CONFIG_PM_SLEEP
static int virtscsi_freeze(struct virtio_device *vdev)
{
- struct Scsi_Host *sh = virtio_scsi_host(vdev);
- struct virtio_scsi *vscsi = shost_priv(sh);
-
- virtscsi_cpu_notif_remove(vscsi);
virtscsi_remove_vqs(vdev);
return 0;
}
@@ -1085,11 +1003,6 @@ static int virtscsi_restore(struct virtio_device *vdev)
if (err)
return err;
- err = virtscsi_cpu_notif_add(vscsi);
- if (err) {
- vdev->config->del_vqs(vdev);
- return err;
- }
virtio_device_ready(vdev);
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
@@ -1144,16 +1057,6 @@ static int __init init(void)
pr_err("mempool_create() for virtscsi_cmd_pool failed\n");
goto error;
}
- ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
- "scsi/virtio:online",
- virtscsi_cpu_online, NULL);
- if (ret < 0)
- goto error;
- virtioscsi_online = ret;
- ret = cpuhp_setup_state_multi(CPUHP_VIRT_SCSI_DEAD, "scsi/virtio:dead",
- NULL, virtscsi_cpu_online);
- if (ret)
- goto error;
ret = register_virtio_driver(&virtio_scsi_driver);
if (ret < 0)
goto error;
@@ -1169,17 +1072,12 @@ static int __init init(void)
kmem_cache_destroy(virtscsi_cmd_cache);
virtscsi_cmd_cache = NULL;
}
- if (virtioscsi_online)
- cpuhp_remove_multi_state(virtioscsi_online);
- cpuhp_remove_multi_state(CPUHP_VIRT_SCSI_DEAD);
return ret;
}
static void __exit fini(void)
{
unregister_virtio_driver(&virtio_scsi_driver);
- cpuhp_remove_multi_state(virtioscsi_online);
- cpuhp_remove_multi_state(CPUHP_VIRT_SCSI_DEAD);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
}
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 921acaaa1601..01aea80a503e 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -26,7 +26,6 @@ enum cpuhp_state {
CPUHP_ARM_OMAP_WAKE_DEAD,
CPUHP_IRQ_POLL_DEAD,
CPUHP_BLOCK_SOFTIRQ_DEAD,
- CPUHP_VIRT_SCSI_DEAD,
CPUHP_ACPI_CPUDRV_DEAD,
CPUHP_S390_PFAULT_DEAD,
CPUHP_BLK_MQ_DEAD,
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] nbd: handle single path failures gracefully
From: Sagi Grimberg @ 2017-02-05 22:31 UTC (permalink / raw)
To: Josef Bacik, linux-block, kernel-team, nbd-general
In-Reply-To: <1486156702-9417-1-git-send-email-jbacik@fb.com>
> Currently if we have multiple connections and one of them goes down we will tear
> down the whole device. However there's no reason we need to do this as we
> could have other connections that are working fine. Deal with this by keeping
> track of the state of the different connections, and if we lose one we mark it
> as dead and send all IO destined for that socket to one of the other healthy
> sockets. Any outstanding requests that were on the dead socket will timeout and
> be re-submitted properly.
Hey Josef,
are you trying to address link failures?
Any reason not to leave DM for this kind of work? Note that the rest
of the block drivers implement periodic reconnects and let DM handle
multipathing.
It took a long time remove all the driver specific multipathing in the
stack.
^ permalink raw reply
* Re: [PATCH] block: don't try Write Same from __blkdev_issue_zeroout
From: Junichi Nomura @ 2017-02-06 1:27 UTC (permalink / raw)
To: Christoph Hellwig, axboe@kernel.dk
Cc: chaitanya.kulkarni@hgst.com, linux-block@vger.kernel.org
In-Reply-To: <20170205171035.5993-1-hch@lst.de>
On 02/06/17 02:10, Christoph Hellwig wrote:
> Write Same can return an error asynchronously if it turns out the
> underlying SCSI device does not support Write Same, which makes a
> proper fallback to other methods in __blkdev_issue_zeroout impossible.
> Thus only issue a Write Same from blkdev_issue_zeroout an don't try it
> at all from __blkdev_issue_zeroout as a non-invasive workaround.
>=20
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reported-by: Junichi Nomura <j-nomura@ce.jp.nec.com>
> Fixes: e73c23ff ("block: add async variant of blkdev_issue_zeroout")
Thank you. I tested your patch and confirmed it works for me.
--=20
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
^ permalink raw reply
* Re: [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices
From: Johannes Thumshirn @ 2017-02-06 7:29 UTC (permalink / raw)
To: Bart Van Assche, hch@lst.de, snitzer@redhat.com
Cc: agk@redhat.com, dm-devel@redhat.com, linux-block@vger.kernel.org,
pbonzini@redhat.com, axboe@kernel.dk
In-Reply-To: <1486158062.2553.12.camel@sandisk.com>
On 02/03/2017 10:41 PM, Bart Van Assche wrote:
> On Fri, 2017-02-03 at 19:17 +0100, Johannes Thumshirn wrote:
>> Forgotten git add? git commit --amend without git add is such a classic
>> mistake on my side as well :-/
> Are you familiar with the -a option of git commit? Just run
>
> git commit -a --amend
Yes I try to train my muscle memory to do so. But this has drawbacks as
well,
like adding unrelated files you've edited and then amend them.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N�rnberg
GF: Felix Imend�rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N�rnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH 2/4] md: introduce bio_clone_slow_mddev_partial()
From: Christoph Hellwig @ 2017-02-06 8:52 UTC (permalink / raw)
To: Ming Lei
Cc: Shaohua Li, Jens Axboe, linux-kernel, linux-raid, linux-block,
Christoph Hellwig, NeilBrown
In-Reply-To: <1486275733-7268-3-git-send-email-tom.leiming@gmail.com>
> +struct bio *bio_clone_slow_mddev_partial(struct bio *bio, gfp_t gfp_mask,
> + struct mddev *mddev, int offset,
> + int size)
> +{
> + struct bio_set *bs;
> +
> + if (!mddev || !mddev->bio_set)
> + bs = fs_bio_set;
> + else
> + bs = mddev->bio_set;
> +
> + return bio_clone_bioset_partial(bio, gfp_mask, bs, offset << 9,
> + size << 9);
> +}
> +EXPORT_SYMBOL_GPL(bio_clone_slow_mddev_partial);
As far as I can tell the caller always has a mddev, and an active
mddev always has a bio_set. So let's just skip this wrapper.
^ permalink raw reply
* Re: [PATCH 4/4] md: fast clone bio in bio_clone_mddev()
From: Christoph Hellwig @ 2017-02-06 8:54 UTC (permalink / raw)
To: Ming Lei
Cc: Shaohua Li, Jens Axboe, linux-kernel, linux-raid, linux-block,
Christoph Hellwig, NeilBrown
In-Reply-To: <1486275733-7268-5-git-send-email-tom.leiming@gmail.com>
On Sun, Feb 05, 2017 at 02:22:13PM +0800, Ming Lei wrote:
> Firstly bio_clone_mddev() is used in raid normal I/O and isn't
> in resync I/O path.
>
> Secondly all the direct access to bvec table in raid happens on
> resync I/O except for write behind of raid1, in which we still
> use bio_clone() for allocating new bvec table.
>
> So this patch replaces bio_clone() with bio_clone_fast()
> in bio_clone_mddev().
Having the _fast in the name would be really useful for the
reader. And as far as I can tell in the callers mddev is never
NULL and neither is ->bio_set, so replacing bio_clone_mddev with
raw calls to bio_clone_fast would be my preference.
^ permalink raw reply
* Re: [PATCH 4/4] md: fast clone bio in bio_clone_mddev()
From: Ming Lei @ 2017-02-06 10:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shaohua Li, Jens Axboe, Linux Kernel Mailing List,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, linux-block,
NeilBrown
In-Reply-To: <20170206085433.GB6411@infradead.org>
On Mon, Feb 6, 2017 at 4:54 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, Feb 05, 2017 at 02:22:13PM +0800, Ming Lei wrote:
>> Firstly bio_clone_mddev() is used in raid normal I/O and isn't
>> in resync I/O path.
>>
>> Secondly all the direct access to bvec table in raid happens on
>> resync I/O except for write behind of raid1, in which we still
>> use bio_clone() for allocating new bvec table.
>>
>> So this patch replaces bio_clone() with bio_clone_fast()
>> in bio_clone_mddev().
>
> Having the _fast in the name would be really useful for the
> reader. And as far as I can tell in the callers mddev is never
> NULL and neither is ->bio_set, so replacing bio_clone_mddev with
In theory, ->bio_set still might be NULL in case of failed memory allocation,
please see md_run().
> raw calls to bio_clone_fast would be my preference.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH 4/4] md: fast clone bio in bio_clone_mddev()
From: Christoph Hellwig @ 2017-02-06 14:24 UTC (permalink / raw)
To: Ming Lei
Cc: Christoph Hellwig, Shaohua Li, Jens Axboe,
Linux Kernel Mailing List,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, linux-block,
NeilBrown
In-Reply-To: <CACVXFVNhB5i_5VJ4596ktLRnEM03GhqhZD-x+E_QwK1kZydTJg@mail.gmail.com>
On Mon, Feb 06, 2017 at 06:43:32PM +0800, Ming Lei wrote:
> In theory, ->bio_set still might be NULL in case of failed memory allocation,
> please see md_run().
And that's something that should be fixed. Silently not having mempool
is very bad behavior.
^ permalink raw reply
* Re: [PATCH 0/4 v2] BDI lifetime fix
From: Thiago Jung Bauermann @ 2017-02-06 14:48 UTC (permalink / raw)
To: Jan Kara
Cc: Jens Axboe, linux-block, Christoph Hellwig, Dan Williams,
Laurent Dufour
In-Reply-To: <20170131125429.14303-1-jack@suse.cz>
Hello,
Am Dienstag, 31. Januar 2017, 13:54:25 BRST schrieb Jan Kara:
> this is a second version of the patch series that attempts to solve the
> problems with the life time of a backing_dev_info structure. Currently it
> lives inside request_queue structure and thus it gets destroyed as soon as
> request queue goes away. However the block device inode still stays around
> and thus inode_to_bdi() call on that inode (e.g. from flusher worker) may
> happen after request queue has been destroyed resulting in oops.
>
> This patch set tries to solve these problems by making backing_dev_info
> independent structure referenced from block device inode. That makes sure
> inode_to_bdi() cannot ever oops. I gave some basic testing to the patches
> in KVM and on a real machine, Dan was running them with libnvdimm test suite
> which was previously triggering the oops and things look good. So they
> should be reasonably healthy. Laurent, if you can give these patches
> testing in your environment where you were triggering the oops, it would be
> nice.
I know you posted a v3, but we are seeing this crash on v2 and looking at
v3's changelog it doesn't seem it would make a difference:
6:mon> th
[c000000003e6b940] c00000000037d15c writeback_sb_inodes+0x30c/0x590
[c000000003e6ba50] c00000000037d4c4 __writeback_inodes_wb+0xe4/0x150
[c000000003e6bab0] c00000000037d91c wb_writeback+0x2fc/0x440
[c000000003e6bb80] c00000000037e778 wb_workfn+0x268/0x580
[c000000003e6bc90] c0000000000f3890 process_one_work+0x1e0/0x590
[c000000003e6bd20] c0000000000f3ce8 worker_thread+0xa8/0x660
[c000000003e6bdc0] c0000000000fd124 kthread+0x154/0x1a0
[c000000003e6be30] c00000000000b4e8 ret_from_kernel_thread+0x5c/0x74
--- Exception: 0 at 0000000000000000
6:mon> r
R00 = c00000000037d15c R16 = c0000001fca60160
R01 = c000000003e6b8e0 R17 = c0000001fca600d8
R02 = c0000000014c3800 R18 = c0000001fca601c8
R03 = c0000001fca600d8 R19 = 0000000000000000
R04 = c0000000036478d0 R20 = 0000000000000000
R05 = 0000000000000000 R21 = c000000003e68000
R06 = 00000001fee70000 R22 = c0000001f49d17c0
R07 = 0001c6ce3a83dfca R23 = c0000001f49d17a0
R08 = 0000000000000000 R24 = 0000000000000000
R09 = 0000000000000000 R25 = c0000001fca60160
R10 = 0000000080000006 R26 = 0000000000000000
R11 = c0000000fb627b68 R27 = 0000000000000000
R12 = 0000000000002200 R28 = 0000000000000001
R13 = c00000000fb83600 R29 = c0000001fca600d8
R14 = c0000000000fcfd8 R30 = c000000003e6bbe0
R15 = 0000000000000000 R31 = 0000000000000000
pc = c0000000003799a0 locked_inode_to_wb_and_lock_list+0x50/0x290
cfar= c0000000005f5568 iowrite16+0x38/0xb0
lr = c00000000037d15c writeback_sb_inodes+0x30c/0x590
msr = 800000000280b033 cr = 24e62882
ctr = c00000000012c110 xer = 0000000000000000 trap = 300
dar = 0000000000000000 dsisr = 40000000
6:mon> sh
[312489.344110] INFO: rcu_sched detected stalls on CPUs/tasks:
[312489.396998] INFO: rcu_sched detected stalls on CPUs/tasks:
[312489.397003] 3-...: (4 ticks this GP) idle=59b/140000000000001/0 softirq=18323196/18323196 fqs=2
[312489.397005] 6-...: (1 GPs behind) idle=86f/140000000000001/0 softirq=18012373/18012374 fqs=2
[312489.397005] (detected by 2, t=47863798 jiffies, g=9340524, c=9340523, q=170)
[312489.505361] rcu_sched kthread starved for 47863823 jiffies! g9340524 c9340523 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
[312489.537334] 3-...: (26 ticks this GP) idle=59b/140000000000000/0 softirq=18323196/18323196 fqs=2
[312489.537395] 6-...: (1 GPs behind) idle=86f/140000000000001/0 softirq=18012373/18012374 fqs=2
[312489.537454] (detected by 0, t=47863836 jiffies, g=9340524, c=9340523, q=170)
[312489.537528] rcu_sched kthread starved for 47863832 jiffies! g9340524 c9340523 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0
[312489.672967] Unable to handle kernel paging request for data at address 0x00000000
[312489.673028] Faulting instruction address: 0xc0000000003799a0
cpu 0x6: Vector: 300 (Data Access) at [c000000003e6b660]
pc: c0000000003799a0: locked_inode_to_wb_and_lock_list+0x50/0x290
lr: c00000000037d15c: writeback_sb_inodes+0x30c/0x590
sp: c000000003e6b8e0
msr: 800000000280b433
dar: 0
dsisr: 40000000
current = 0xc000000003646e00
paca = 0xc00000000fb83600 softe: 0 irq_happened: 0x01
pid = 8569, comm = kworker/u16:5
Linux version 4.10.0-rc3jankarav2+ (bauermann@u1604le) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #3 SMP Wed Feb 1 13:22:47 BRST 2017
enter ? for help
6:mon>
It took more than a day under I/O stress test to crash, so it seems to be a
hard to hit race condition. PC is at:
$ addr2line -e /usr/lib/debug/vmlinux-4.10.0-rc3jankarav2+ c0000000003799a0
wb_get at /home/bauermann/src/linux/./include/linux/backing-dev-defs.h:218
(inlined by) locked_inode_to_wb_and_lock_list at /home/bauermann/src/linux/fs/fs-writeback.c:281
Which is:
216 static inline void wb_get(struct bdi_writeback *wb)
217 {
218 if (wb != &wb->bdi->wb)
219 percpu_ref_get(&wb->refcnt);
220 }
So it looks like wb->bdi is NULL.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 0/4 v2] BDI lifetime fix
From: Thiago Jung Bauermann @ 2017-02-06 15:26 UTC (permalink / raw)
To: Jan Kara
Cc: Jens Axboe, linux-block, Christoph Hellwig, Dan Williams,
Laurent Dufour
In-Reply-To: <2851869.q2N89k4IqL@morokweng>
Am Montag, 6. Februar 2017, 12:48:42 BRST schrieb Thiago Jung Bauermann:
> 216 static inline void wb_get(struct bdi_writeback *wb)
> 217 {
> 218 if (wb != &wb->bdi->wb)
> 219 percpu_ref_get(&wb->refcnt);
> 220 }
>
> So it looks like wb->bdi is NULL.
Sorry, looking a little deeper, it's actually wb which is NULL:
./include/linux/backing-dev.h:
371 return inode->i_wb;
0xc00000000037999c <+76>: ld r31,256(r29)
./include/linux/backing-dev-defs.h:
218 if (wb != &wb->bdi->wb)
0xc0000000003799a0 <+80>: ld r9,0(r31)
0xc0000000003799a4 <+84>: addi r9,r9,88
0xc0000000003799a8 <+88>: cmpld cr7,r31,r9
0xc0000000003799ac <+92>: beq cr7,0xc0000000003799e0
<locked_inode_to_wb_and_lock_list+144>
We can see above that inode->i_wb is in r31, and the machine crashed at
0xc0000000003799a0 so it was trying to dereference wb and crashed.
r31 is NULL in the crash information.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] nbd: freeze the queue before making changes
From: Josef Bacik @ 2017-02-06 15:54 UTC (permalink / raw)
To: linux-block, kernel-team, nbd-general, axboe
The way we make changes to the NBD device is inherently racey, as we
could be in the middle of a request and suddenly change the number of
connections. In practice this isn't a big deal, but with timeouts we
have to take the config_lock in order to protect ourselves since it is
important those values don't change. Fix this by freezing the queue
before we do any of our device operations.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
drivers/block/nbd.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 164a548..f8b3ecd 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -199,7 +199,6 @@ static enum blk_eh_timer_return nbd_xmit_timeout(struct request *req,
if (nbd->num_connections > 1) {
dev_err_ratelimited(nbd_to_dev(nbd),
"Connection timed out, retrying\n");
- mutex_lock(&nbd->config_lock);
/*
* Hooray we have more connections, requeue this IO, the submit
* path will put it on a real connection.
@@ -213,11 +212,9 @@ static enum blk_eh_timer_return nbd_xmit_timeout(struct request *req,
kernel_sock_shutdown(nsock->sock, SHUT_RDWR);
mutex_unlock(&nsock->tx_lock);
}
- mutex_unlock(&nbd->config_lock);
blk_mq_requeue_request(req, true);
return BLK_EH_RESET_TIMER;
}
- mutex_unlock(&nbd->config_lock);
} else {
dev_err_ratelimited(nbd_to_dev(nbd),
"Connection timed out\n");
@@ -225,9 +222,7 @@ static enum blk_eh_timer_return nbd_xmit_timeout(struct request *req,
set_bit(NBD_TIMEDOUT, &nbd->runtime_flags);
req->errors++;
- mutex_lock(&nbd->config_lock);
sock_shutdown(nbd);
- mutex_unlock(&nbd->config_lock);
return BLK_EH_HANDLED;
}
@@ -756,7 +751,9 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
return -EINVAL;
mutex_unlock(&nbd->config_lock);
+ blk_mq_unfreeze_queue(nbd->disk->queue);
fsync_bdev(bdev);
+ blk_mq_freeze_queue(nbd->disk->queue);
mutex_lock(&nbd->config_lock);
/* Check again after getting mutex back. */
@@ -870,10 +867,14 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
args[i].index = i;
queue_work(recv_workqueue, &args[i].work);
}
+ blk_mq_unfreeze_queue(nbd->disk->queue);
+
wait_event_interruptible(nbd->recv_wq,
atomic_read(&nbd->recv_threads) == 0);
for (i = 0; i < num_connections; i++)
flush_work(&args[i].work);
+
+ blk_mq_freeze_queue(nbd->disk->queue);
nbd_dev_dbg_close(nbd);
nbd_size_clear(nbd, bdev);
device_remove_file(disk_to_dev(nbd->disk), &pid_attr);
@@ -924,9 +925,11 @@ static int nbd_ioctl(struct block_device *bdev, fmode_t mode,
BUG_ON(nbd->magic != NBD_MAGIC);
+ blk_mq_freeze_queue(nbd->disk->queue);
mutex_lock(&nbd->config_lock);
error = __nbd_ioctl(bdev, nbd, cmd, arg);
mutex_unlock(&nbd->config_lock);
+ blk_mq_unfreeze_queue(nbd->disk->queue);
return error;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] block: don't try Write Same from __blkdev_issue_zeroout
From: Jens Axboe @ 2017-02-06 16:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: j-nomura, chaitanya.kulkarni, linux-block
In-Reply-To: <20170205171035.5993-1-hch@lst.de>
On 02/05/2017 10:10 AM, Christoph Hellwig wrote:
> Write Same can return an error asynchronously if it turns out the
> underlying SCSI device does not support Write Same, which makes a
> proper fallback to other methods in __blkdev_issue_zeroout impossible.
> Thus only issue a Write Same from blkdev_issue_zeroout an don't try it
> at all from __blkdev_issue_zeroout as a non-invasive workaround.
Thanks, added for 4.10.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 1/6] genirq: allow assigning affinity to present but not online CPUs
From: Keith Busch @ 2017-02-06 17:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Joe Korty, linux-nvme, linux-block, linux-kernel
In-Reply-To: <20170205164023.GA9281@lst.de>
On Sun, Feb 05, 2017 at 05:40:23PM +0100, Christoph Hellwig wrote:
> Hi Joe,
>
> On Fri, Feb 03, 2017 at 08:58:09PM -0500, Joe Korty wrote:
> > IIRC, some years ago I ran across a customer system where
> > the #cpus_present was twice as big as #cpus_possible.
> >
> > Hyperthreading was turned off in the BIOS so it was not
> > entirely out of line for the extra cpus to be declared
> > present, even though none of them would ever be available
> > for use.
>
> This sounds like a system we should quirk around instead of optimizing
> for it. Unless I totally misunderstand the idea behind cpu_possible
> and cpu_present.
Can we use the online CPUs and create a new hot-cpu notifier to the nvme
driver to free/reallocate as needed? We were doing that before blk-mq. Now
blk-mq can change the number hardware contexts on a live queue, so we
can reintroduce that behavior to nvme and only allocate what we need.
^ permalink raw reply
* Re: [PATCH 1/6] genirq: allow assigning affinity to present but not online CPUs
From: Christoph Hellwig @ 2017-02-06 17:03 UTC (permalink / raw)
To: Keith Busch
Cc: Christoph Hellwig, Joe Korty, linux-nvme, linux-block,
linux-kernel
In-Reply-To: <20170206170304.GF24601@localhost.localdomain>
On Mon, Feb 06, 2017 at 12:03:05PM -0500, Keith Busch wrote:
> Can we use the online CPUs and create a new hot-cpu notifier to the nvme
> driver to free/reallocate as needed? We were doing that before blk-mq. Now
> blk-mq can change the number hardware contexts on a live queue, so we
> can reintroduce that behavior to nvme and only allocate what we need.
That could be a next step, but given how badly I keep messing up core
IRQ bits we'll probably want to wait for two rewrites of those bits
from Thomas before moving on :)
^ permalink raw reply
* [PATCH v2] blk-mq-sched: separate mark hctx and queue restart operations
From: Omar Sandoval @ 2017-02-06 19:24 UTC (permalink / raw)
To: Jens Axboe, linux-block; +Cc: kernel-team
From: Omar Sandoval <osandov@fb.com>
In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart()
after we dispatch requests left over on our hardware queue dispatch
list. This is so we'll go back and dispatch requests from the scheduler.
In this case, it's only necessary to restart the hardware queue that we
are running; there's no reason to run other hardware queues just because
we are using shared tags.
So, split out blk_mq_sched_mark_restart() into two operations, one for
just the hardware queue and one for the whole request queue. The core
code uses both, and I/O schedulers may also want to use them.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
Patch based on block/for-next.
block/blk-mq-sched.c | 2 +-
block/blk-mq-sched.h | 25 ++++++++++++++++++-------
block/blk-mq.c | 5 ++++-
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index ee455e7cf9d8..7538565359ea 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -201,7 +201,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
* needing a restart in that case.
*/
if (!list_empty(&rq_list)) {
- blk_mq_sched_mark_restart(hctx);
+ blk_mq_sched_mark_restart_hctx(hctx);
blk_mq_dispatch_rq_list(hctx, &rq_list);
} else if (!e || !e->type->ops.mq.dispatch_request) {
blk_mq_flush_busy_ctxs(hctx, &rq_list);
diff --git a/block/blk-mq-sched.h b/block/blk-mq-sched.h
index 5954859c8670..46788ef2b3db 100644
--- a/block/blk-mq-sched.h
+++ b/block/blk-mq-sched.h
@@ -121,16 +121,27 @@ static inline bool blk_mq_sched_has_work(struct blk_mq_hw_ctx *hctx)
return false;
}
-static inline void blk_mq_sched_mark_restart(struct blk_mq_hw_ctx *hctx)
+/*
+ * Mark a hardware queue as needing a restart.
+ */
+static inline void blk_mq_sched_mark_restart_hctx(struct blk_mq_hw_ctx *hctx)
{
- if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state)) {
+ if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state))
set_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state);
- if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
- struct request_queue *q = hctx->queue;
+}
+
+/*
+ * Mark a hardware queue and the request queue it belongs to as needing a
+ * restart.
+ */
+static inline void blk_mq_sched_mark_restart_queue(struct blk_mq_hw_ctx *hctx)
+{
+ struct request_queue *q = hctx->queue;
- if (!test_bit(QUEUE_FLAG_RESTART, &q->queue_flags))
- set_bit(QUEUE_FLAG_RESTART, &q->queue_flags);
- }
+ if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state)) {
+ set_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state);
+ if (!test_bit(QUEUE_FLAG_RESTART, &q->queue_flags))
+ set_bit(QUEUE_FLAG_RESTART, &q->queue_flags);
}
}
diff --git a/block/blk-mq.c b/block/blk-mq.c
index be183e6115a1..a494c0b589d5 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -937,7 +937,10 @@ bool blk_mq_dispatch_rq_list(struct blk_mq_hw_ctx *hctx, struct list_head *list)
* in case the needed IO completed right before we
* marked the queue as needing a restart.
*/
- blk_mq_sched_mark_restart(hctx);
+ if (hctx->flags & BLK_MQ_F_TAG_SHARED)
+ blk_mq_sched_mark_restart_queue(hctx);
+ else
+ blk_mq_sched_mark_restart_hctx(hctx);
if (!blk_mq_get_driver_tag(rq, &hctx, false))
break;
}
--
2.11.1
^ permalink raw reply related
* Re: [PATCH v2] blk-mq-sched: separate mark hctx and queue restart operations
From: Jens Axboe @ 2017-02-06 19:39 UTC (permalink / raw)
To: Omar Sandoval, linux-block; +Cc: kernel-team
In-Reply-To: <0ec9b1167d22966cdf77a1d5140499493ea888a2.1486408944.git.osandov@fb.com>
On 02/06/2017 12:24 PM, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart()
> after we dispatch requests left over on our hardware queue dispatch
> list. This is so we'll go back and dispatch requests from the scheduler.
> In this case, it's only necessary to restart the hardware queue that we
> are running; there's no reason to run other hardware queues just because
> we are using shared tags.
>
> So, split out blk_mq_sched_mark_restart() into two operations, one for
> just the hardware queue and one for the whole request queue. The core
> code uses both, and I/O schedulers may also want to use them.
>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
> Patch based on block/for-next.
>
> block/blk-mq-sched.c | 2 +-
> block/blk-mq-sched.h | 25 ++++++++++++++++++-------
> block/blk-mq.c | 5 ++++-
> 3 files changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> index ee455e7cf9d8..7538565359ea 100644
> --- a/block/blk-mq-sched.c
> +++ b/block/blk-mq-sched.c
> @@ -201,7 +201,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
> * needing a restart in that case.
> */
> if (!list_empty(&rq_list)) {
> - blk_mq_sched_mark_restart(hctx);
> + blk_mq_sched_mark_restart_hctx(hctx);
> blk_mq_dispatch_rq_list(hctx, &rq_list);
What if we dispatched nothing on this hardware queue, and it currently
doesn't have any IO pending?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] blk-mq-sched: separate mark hctx and queue restart operations
From: Omar Sandoval @ 2017-02-06 19:53 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, kernel-team
In-Reply-To: <182de41f-33d3-bbf8-c591-9e577b0f1762@fb.com>
On Mon, Feb 06, 2017 at 12:39:57PM -0700, Jens Axboe wrote:
> On 02/06/2017 12:24 PM, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@fb.com>
> >
> > In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart()
> > after we dispatch requests left over on our hardware queue dispatch
> > list. This is so we'll go back and dispatch requests from the scheduler.
> > In this case, it's only necessary to restart the hardware queue that we
> > are running; there's no reason to run other hardware queues just because
> > we are using shared tags.
> >
> > So, split out blk_mq_sched_mark_restart() into two operations, one for
> > just the hardware queue and one for the whole request queue. The core
> > code uses both, and I/O schedulers may also want to use them.
> >
> > Signed-off-by: Omar Sandoval <osandov@fb.com>
> > ---
> > Patch based on block/for-next.
> >
> > block/blk-mq-sched.c | 2 +-
> > block/blk-mq-sched.h | 25 ++++++++++++++++++-------
> > block/blk-mq.c | 5 ++++-
> > 3 files changed, 23 insertions(+), 9 deletions(-)
> >
> > diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> > index ee455e7cf9d8..7538565359ea 100644
> > --- a/block/blk-mq-sched.c
> > +++ b/block/blk-mq-sched.c
> > @@ -201,7 +201,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
> > * needing a restart in that case.
> > */
> > if (!list_empty(&rq_list)) {
> > - blk_mq_sched_mark_restart(hctx);
> > + blk_mq_sched_mark_restart_hctx(hctx);
> > blk_mq_dispatch_rq_list(hctx, &rq_list);
>
> What if we dispatched nothing on this hardware queue, and it currently
> doesn't have any IO pending?
Hm, so there are two ways that could happen. If it's because
->queue_rq() returned BLK_MQ_RQ_QUEUE_BUSY, then the driver is supposed
to kick I/O off again, right?
If it's because we failed to get a driver tag, then we'll call
blk_mq_sched_mark_restart_queue() in the shared case. I just realized
that there's a bug there, though. Since we already set the hctx restart
bit, we won't set the queue restart bit. The below should work, and
makes more sense in general.
Or were you thinking of something else?
>From c6fb0a75bd3169d09d0da0dd2da82f20f20b8574 Mon Sep 17 00:00:00 2001
Message-Id: <c6fb0a75bd3169d09d0da0dd2da82f20f20b8574.1486410655.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Date: Fri, 3 Feb 2017 11:06:37 -0800
Subject: [PATCH v3] blk-mq-sched: separate mark hctx and queue restart
operations
In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart()
after we dispatch requests left over on our hardware queue dispatch
list. This is so we'll go back and dispatch requests from the scheduler.
In this case, it's only necessary to restart the hardware queue that we
are running; there's no reason to run other hardware queues just because
we are using shared tags.
So, split out blk_mq_sched_mark_restart() into two operations, one for
just the hardware queue and one for the whole request queue. The core
code uses both, and I/O schedulers may also want to use them.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
block/blk-mq-sched.c | 2 +-
block/blk-mq-sched.h | 26 ++++++++++++++++++--------
block/blk-mq.c | 5 ++++-
3 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index ee455e7cf9d8..7538565359ea 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -201,7 +201,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
* needing a restart in that case.
*/
if (!list_empty(&rq_list)) {
- blk_mq_sched_mark_restart(hctx);
+ blk_mq_sched_mark_restart_hctx(hctx);
blk_mq_dispatch_rq_list(hctx, &rq_list);
} else if (!e || !e->type->ops.mq.dispatch_request) {
blk_mq_flush_busy_ctxs(hctx, &rq_list);
diff --git a/block/blk-mq-sched.h b/block/blk-mq-sched.h
index 5954859c8670..36cc68481b0c 100644
--- a/block/blk-mq-sched.h
+++ b/block/blk-mq-sched.h
@@ -121,17 +121,27 @@ static inline bool blk_mq_sched_has_work(struct blk_mq_hw_ctx *hctx)
return false;
}
-static inline void blk_mq_sched_mark_restart(struct blk_mq_hw_ctx *hctx)
+/*
+ * Mark a hardware queue as needing a restart.
+ */
+static inline void blk_mq_sched_mark_restart_hctx(struct blk_mq_hw_ctx *hctx)
{
- if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state)) {
+ if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state))
set_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state);
- if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
- struct request_queue *q = hctx->queue;
+}
+
+/*
+ * Mark a hardware queue and the request queue it belongs to as needing a
+ * restart.
+ */
+static inline void blk_mq_sched_mark_restart_queue(struct blk_mq_hw_ctx *hctx)
+{
+ struct request_queue *q = hctx->queue;
- if (!test_bit(QUEUE_FLAG_RESTART, &q->queue_flags))
- set_bit(QUEUE_FLAG_RESTART, &q->queue_flags);
- }
- }
+ if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state))
+ set_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state);
+ if (!test_bit(QUEUE_FLAG_RESTART, &q->queue_flags))
+ set_bit(QUEUE_FLAG_RESTART, &q->queue_flags);
}
static inline bool blk_mq_sched_needs_restart(struct blk_mq_hw_ctx *hctx)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index be183e6115a1..a494c0b589d5 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -937,7 +937,10 @@ bool blk_mq_dispatch_rq_list(struct blk_mq_hw_ctx *hctx, struct list_head *list)
* in case the needed IO completed right before we
* marked the queue as needing a restart.
*/
- blk_mq_sched_mark_restart(hctx);
+ if (hctx->flags & BLK_MQ_F_TAG_SHARED)
+ blk_mq_sched_mark_restart_queue(hctx);
+ else
+ blk_mq_sched_mark_restart_hctx(hctx);
if (!blk_mq_get_driver_tag(rq, &hctx, false))
break;
}
--
2.11.1
^ permalink raw reply related
* Re: [PATCH v2] blk-mq-sched: separate mark hctx and queue restart operations
From: Jens Axboe @ 2017-02-06 20:07 UTC (permalink / raw)
To: Omar Sandoval; +Cc: linux-block, kernel-team
In-Reply-To: <20170206195330.GB20714@vader>
On 02/06/2017 12:53 PM, Omar Sandoval wrote:
> On Mon, Feb 06, 2017 at 12:39:57PM -0700, Jens Axboe wrote:
>> On 02/06/2017 12:24 PM, Omar Sandoval wrote:
>>> From: Omar Sandoval <osandov@fb.com>
>>>
>>> In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart()
>>> after we dispatch requests left over on our hardware queue dispatch
>>> list. This is so we'll go back and dispatch requests from the scheduler.
>>> In this case, it's only necessary to restart the hardware queue that we
>>> are running; there's no reason to run other hardware queues just because
>>> we are using shared tags.
>>>
>>> So, split out blk_mq_sched_mark_restart() into two operations, one for
>>> just the hardware queue and one for the whole request queue. The core
>>> code uses both, and I/O schedulers may also want to use them.
>>>
>>> Signed-off-by: Omar Sandoval <osandov@fb.com>
>>> ---
>>> Patch based on block/for-next.
>>>
>>> block/blk-mq-sched.c | 2 +-
>>> block/blk-mq-sched.h | 25 ++++++++++++++++++-------
>>> block/blk-mq.c | 5 ++++-
>>> 3 files changed, 23 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
>>> index ee455e7cf9d8..7538565359ea 100644
>>> --- a/block/blk-mq-sched.c
>>> +++ b/block/blk-mq-sched.c
>>> @@ -201,7 +201,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
>>> * needing a restart in that case.
>>> */
>>> if (!list_empty(&rq_list)) {
>>> - blk_mq_sched_mark_restart(hctx);
>>> + blk_mq_sched_mark_restart_hctx(hctx);
>>> blk_mq_dispatch_rq_list(hctx, &rq_list);
>>
>> What if we dispatched nothing on this hardware queue, and it currently
>> doesn't have any IO pending?
>
> Hm, so there are two ways that could happen. If it's because
> ->queue_rq() returned BLK_MQ_RQ_QUEUE_BUSY, then the driver is supposed
> to kick I/O off again, right?
>
> If it's because we failed to get a driver tag, then we'll call
> blk_mq_sched_mark_restart_queue() in the shared case. I just realized
> that there's a bug there, though. Since we already set the hctx restart
> bit, we won't set the queue restart bit. The below should work, and
> makes more sense in general.
>
> Or were you thinking of something else?
No, I think that covers it, I had not read far enough either to see that
you handle the shared tag case for tag starvation in the caller.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] blk-mq-sched: separate mark hctx and queue restart operations
From: Omar Sandoval @ 2017-02-06 20:15 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, kernel-team
In-Reply-To: <f26e16b9-2e54-3e06-adca-190c952804a7@fb.com>
On Mon, Feb 06, 2017 at 01:07:41PM -0700, Jens Axboe wrote:
> On 02/06/2017 12:53 PM, Omar Sandoval wrote:
> > On Mon, Feb 06, 2017 at 12:39:57PM -0700, Jens Axboe wrote:
> >> On 02/06/2017 12:24 PM, Omar Sandoval wrote:
> >>> From: Omar Sandoval <osandov@fb.com>
> >>>
> >>> In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart()
> >>> after we dispatch requests left over on our hardware queue dispatch
> >>> list. This is so we'll go back and dispatch requests from the scheduler.
> >>> In this case, it's only necessary to restart the hardware queue that we
> >>> are running; there's no reason to run other hardware queues just because
> >>> we are using shared tags.
> >>>
> >>> So, split out blk_mq_sched_mark_restart() into two operations, one for
> >>> just the hardware queue and one for the whole request queue. The core
> >>> code uses both, and I/O schedulers may also want to use them.
> >>>
> >>> Signed-off-by: Omar Sandoval <osandov@fb.com>
> >>> ---
> >>> Patch based on block/for-next.
> >>>
> >>> block/blk-mq-sched.c | 2 +-
> >>> block/blk-mq-sched.h | 25 ++++++++++++++++++-------
> >>> block/blk-mq.c | 5 ++++-
> >>> 3 files changed, 23 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> >>> index ee455e7cf9d8..7538565359ea 100644
> >>> --- a/block/blk-mq-sched.c
> >>> +++ b/block/blk-mq-sched.c
> >>> @@ -201,7 +201,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
> >>> * needing a restart in that case.
> >>> */
> >>> if (!list_empty(&rq_list)) {
> >>> - blk_mq_sched_mark_restart(hctx);
> >>> + blk_mq_sched_mark_restart_hctx(hctx);
> >>> blk_mq_dispatch_rq_list(hctx, &rq_list);
> >>
> >> What if we dispatched nothing on this hardware queue, and it currently
> >> doesn't have any IO pending?
> >
> > Hm, so there are two ways that could happen. If it's because
> > ->queue_rq() returned BLK_MQ_RQ_QUEUE_BUSY, then the driver is supposed
> > to kick I/O off again, right?
> >
> > If it's because we failed to get a driver tag, then we'll call
> > blk_mq_sched_mark_restart_queue() in the shared case. I just realized
> > that there's a bug there, though. Since we already set the hctx restart
> > bit, we won't set the queue restart bit. The below should work, and
> > makes more sense in general.
> >
> > Or were you thinking of something else?
>
> No, I think that covers it, I had not read far enough either to see that
> you handle the shared tag case for tag starvation in the caller.
Yup, I considered making that its own helper but I figured we could do
that when we need the same logic elsewhere.
^ permalink raw reply
* [PATCH] blk-mq-sched: (un)register elevator when (un)registering queue
From: Omar Sandoval @ 2017-02-06 20:52 UTC (permalink / raw)
To: Jens Axboe, linux-block; +Cc: kernel-team
From: Omar Sandoval <osandov@fb.com>
I noticed that when booting with a default blk-mq I/O scheduler, the
/sys/block/*/queue/iosched directory was missing. However, switching
after boot did create the directory. This is because we skip the initial
elevator register/unregister when we don't have a ->request_fn(), but we
should still do it for the ->mq_ops case.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
block/blk-sysfs.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 3ce1217778f4..48032c4759a7 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -903,16 +903,15 @@ int blk_register_queue(struct gendisk *disk)
blk_wb_init(q);
- if (!q->request_fn)
- return 0;
-
- ret = elv_register_queue(q);
- if (ret) {
- kobject_uevent(&q->kobj, KOBJ_REMOVE);
- kobject_del(&q->kobj);
- blk_trace_remove_sysfs(dev);
- kobject_put(&dev->kobj);
- return ret;
+ if (q->request_fn || (q->mq_ops && q->elevator)) {
+ ret = elv_register_queue(q);
+ if (ret) {
+ kobject_uevent(&q->kobj, KOBJ_REMOVE);
+ kobject_del(&q->kobj);
+ blk_trace_remove_sysfs(dev);
+ kobject_put(&dev->kobj);
+ return ret;
+ }
}
return 0;
@@ -928,7 +927,7 @@ void blk_unregister_queue(struct gendisk *disk)
if (q->mq_ops)
blk_mq_unregister_dev(disk_to_dev(disk), q);
- if (q->request_fn)
+ if (q->request_fn || (q->mq_ops && q->elevator))
elv_unregister_queue(q);
kobject_uevent(&q->kobj, KOBJ_REMOVE);
--
2.11.1
^ permalink raw reply related
* Re: [PATCH] blk-mq-sched: (un)register elevator when (un)registering queue
From: Jens Axboe @ 2017-02-06 20:56 UTC (permalink / raw)
To: Omar Sandoval, linux-block; +Cc: kernel-team
In-Reply-To: <ff62b5d76fa68f6595446d2a6c4aa13db4113d71.1486414181.git.osandov@fb.com>
On 02/06/2017 01:52 PM, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> I noticed that when booting with a default blk-mq I/O scheduler, the
> /sys/block/*/queue/iosched directory was missing. However, switching
> after boot did create the directory. This is because we skip the initial
> elevator register/unregister when we don't have a ->request_fn(), but we
> should still do it for the ->mq_ops case.
Good catch Omar, applied.
--
Jens Axboe
^ permalink raw reply
* Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup
From: James Bottomley @ 2017-02-07 0:14 UTC (permalink / raw)
To: Dan Williams, Christoph Hellwig
Cc: kernel test robot, Jens Axboe, Bart Van Assche,
Martin K. Petersen, Jan Kara, Omar Sandoval, Omar Sandoval, LKML,
Jens Axboe, LKP, linux-scsi, linux-block
In-Reply-To: <CAPcyv4gE0+3pZQV=V75wxddFVhWeAz1abfJ=q8D1Zi+8Oi17rA@mail.gmail.com>
On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
> On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig <hch@lst.de> wrote:
> > Dan,
> >
> > can you please quote your emails? I can't find any content
> > inbetween all these quotes.
>
> Sorry, I'm using gmail, but I'll switch to attaching the logs.
>
> So with help from Xiaolong I was able to reproduce this, and it does
> not appear to be a regression. We simply change the failure output of
> an existing bug. Attached is a log of the same test on v4.10-rc7
> (i.e. without the recent block/scsi fixes), and it shows sda being
> registered twice.
>
> "[ 6.647077] kobject (d5078ca4): tried to init an initialized
> object, something is seriously wrong."
>
> The change that "scsi, block: fix duplicate bdi name registration
> crashes" makes is to properly try to register sdb since the sda devt
> is still alive. However that's not a fix because we've managed to
> call blk_register_queue() twice on the same queue.
OK, time to involve others: linux-scsi and linux-block cc'd and I've
inserted the log below.
James
---
[ 5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
[ 5.969672] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
[ 5.971895] scsi 0:0:0:0: Direct-Access Linux scsi_debug 0186 PQ: 0 ANSI: 7
[ 6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.026965] sd 0:0:0:0: [sda] Write Protect is off
[ 6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.546964] sd 0:0:0:0: [sda] Write Protect is off
[ 6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
[ 6.648723] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.649811] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.651418] Workqueue: events_unbound async_run_entry_fn
[ 6.652347] Call Trace:
[ 6.652987] dump_stack+0x79/0xa4
[ 6.653716] kobject_init+0x75/0x90
[ 6.654452] blk_mq_register_dev+0x2a/0x110
[ 6.655269] blk_register_queue+0x7b/0x130
[ 6.656080] device_add_disk+0x1c6/0x460
[ 6.656866] sd_probe_async+0xf1/0x1c0
[ 6.657634] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.658501] async_run_entry_fn+0x30/0x190
[ 6.659311] ? process_one_work+0x12f/0x430
[ 6.660113] process_one_work+0x1aa/0x430
[ 6.660901] ? process_one_work+0x12f/0x430
[ 6.661716] worker_thread+0x1dd/0x470
[ 6.662479] kthread+0xd4/0x100
[ 6.663175] ? process_one_work+0x430/0x430
[ 6.663984] ? __kthread_create_on_node+0x180/0x180
[ 6.664869] ret_from_fork+0x21/0x2c
[ 6.665638] kobject (ffab51ec): tried to init an initialized object, something is seriously wrong.
[ 6.667290] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.668372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.669984] Workqueue: events_unbound async_run_entry_fn
[ 6.670909] Call Trace:
[ 6.671540] dump_stack+0x79/0xa4
[ 6.672266] kobject_init+0x75/0x90
[ 6.673011] blk_mq_register_dev+0x4c/0x110
[ 6.673832] blk_register_queue+0x7b/0x130
[ 6.674633] device_add_disk+0x1c6/0x460
[ 6.675413] sd_probe_async+0xf1/0x1c0
[ 6.676191] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.677057] async_run_entry_fn+0x30/0x190
[ 6.677860] ? process_one_work+0x12f/0x430
[ 6.678667] process_one_work+0x1aa/0x430
[ 6.679455] ? process_one_work+0x12f/0x430
[ 6.680269] worker_thread+0x1dd/0x470
[ 6.681036] kthread+0xd4/0x100
[ 6.681737] ? process_one_work+0x430/0x430
[ 6.682540] ? __kthread_create_on_node+0x180/0x180
[ 6.683420] ret_from_fork+0x21/0x2c
[ 6.684207] ------------[ cut here ]------------
[ 6.685067] WARNING: CPU: 0 PID: 99 at ./include/linux/kref.h:46 kobject_get+0x7f/0x90
[ 6.686592] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.687680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.689280] Workqueue: events_unbound async_run_entry_fn
[ 6.690208] Call Trace:
[ 6.690843] dump_stack+0x79/0xa4
[ 6.691563] __warn+0xd2/0xf0
[ 6.692246] ? kobject_get+0x7f/0x90
[ 6.692992] warn_slowpath_null+0x25/0x30
[ 6.693787] kobject_get+0x7f/0x90
[ 6.694505] kobject_add_internal+0x2e/0x360
[ 6.695322] ? kfree_const+0x18/0x20
[ 6.696071] ? kobject_set_name_vargs+0x62/0x80
[ 6.696914] kobject_add+0x35/0x80
[ 6.697642] blk_mq_register_hctx+0x95/0xc0
[ 6.698447] blk_mq_register_dev+0xc9/0x110
[ 6.699255] blk_register_queue+0x7b/0x130
[ 6.700059] device_add_disk+0x1c6/0x460
[ 6.700849] sd_probe_async+0xf1/0x1c0
[ 6.701628] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.702484] async_run_entry_fn+0x30/0x190
[ 6.703284] ? process_one_work+0x12f/0x430
[ 6.704098] process_one_work+0x1aa/0x430
[ 6.704894] ? process_one_work+0x12f/0x430
[ 6.705704] worker_thread+0x1dd/0x470
[ 6.706488] kthread+0xd4/0x100
[ 6.707198] ? process_one_work+0x430/0x430
[ 6.708016] ? __kthread_create_on_node+0x180/0x180
[ 6.708909] ret_from_fork+0x21/0x2c
[ 6.709676] ---[ end trace 1a7726d7c3d3c8d0 ]---
[ 5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
[ 5.969672] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
[ 5.971895] scsi 0:0:0:0: Direct-Access Linux scsi_debug 0186 PQ: 0 ANSI: 7
[ 6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.026965] sd 0:0:0:0: [sda] Write Protect is off
[ 6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.546964] sd 0:0:0:0: [sda] Write Protect is off
[ 6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
[ 6.648723] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.649811] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.651418] Workqueue: events_unbound async_run_entry_fn
[ 6.652347] Call Trace:
[ 6.652987] dump_stack+0x79/0xa4
[ 6.653716] kobject_init+0x75/0x90
[ 6.654452] blk_mq_register_dev+0x2a/0x110
[ 6.655269] blk_register_queue+0x7b/0x130
[ 6.656080] device_add_disk+0x1c6/0x460
[ 6.656866] sd_probe_async+0xf1/0x1c0
[ 6.657634] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.658501] async_run_entry_fn+0x30/0x190
[ 6.659311] ? process_one_work+0x12f/0x430
[ 6.660113] process_one_work+0x1aa/0x430
[ 6.660901] ? process_one_work+0x12f/0x430
[ 6.661716] worker_thread+0x1dd/0x470
[ 6.662479] kthread+0xd4/0x100
[ 6.663175] ? process_one_work+0x430/0x430
[ 6.663984] ? __kthread_create_on_node+0x180/0x180
[ 6.664869] ret_from_fork+0x21/0x2c
[ 6.665638] kobject (ffab51ec): tried to init an initialized object, something is seriously wrong.
[ 6.667290] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.668372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.669984] Workqueue: events_unbound async_run_entry_fn
[ 6.670909] Call Trace:
[ 6.671540] dump_stack+0x79/0xa4
[ 6.672266] kobject_init+0x75/0x90
[ 6.673011] blk_mq_register_dev+0x4c/0x110
[ 6.673832] blk_register_queue+0x7b/0x130
[ 6.674633] device_add_disk+0x1c6/0x460
[ 6.675413] sd_probe_async+0xf1/0x1c0
[ 6.676191] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.677057] async_run_entry_fn+0x30/0x190
[ 6.677860] ? process_one_work+0x12f/0x430
[ 6.678667] process_one_work+0x1aa/0x430
[ 6.679455] ? process_one_work+0x12f/0x430
[ 6.680269] worker_thread+0x1dd/0x470
[ 6.681036] kthread+0xd4/0x100
[ 6.681737] ? process_one_work+0x430/0x430
[ 6.682540] ? __kthread_create_on_node+0x180/0x180
[ 6.683420] ret_from_fork+0x21/0x2c
[ 6.684207] ------------[ cut here ]------------
[ 6.685067] WARNING: CPU: 0 PID: 99 at ./include/linux/kref.h:46 kobject_get+0x7f/0x90
[ 6.686592] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.687680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.689280] Workqueue: events_unbound async_run_entry_fn
[ 6.690208] Call Trace:
[ 6.690843] dump_stack+0x79/0xa4
[ 6.691563] __warn+0xd2/0xf0
[ 6.692246] ? kobject_get+0x7f/0x90
[ 6.692992] warn_slowpath_null+0x25/0x30
[ 6.693787] kobject_get+0x7f/0x90
[ 6.694505] kobject_add_internal+0x2e/0x360
[ 6.695322] ? kfree_const+0x18/0x20
[ 6.696071] ? kobject_set_name_vargs+0x62/0x80
[ 6.696914] kobject_add+0x35/0x80
[ 6.697642] blk_mq_register_hctx+0x95/0xc0
[ 6.698447] blk_mq_register_dev+0xc9/0x110
[ 6.699255] blk_register_queue+0x7b/0x130
[ 6.700059] device_add_disk+0x1c6/0x460
[ 6.700849] sd_probe_async+0xf1/0x1c0
[ 6.701628] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.702484] async_run_entry_fn+0x30/0x190
[ 6.703284] ? process_one_work+0x12f/0x430
[ 6.704098] process_one_work+0x1aa/0x430
[ 6.704894] ? process_one_work+0x12f/0x430
[ 6.705704] worker_thread+0x1dd/0x470
[ 6.706488] kthread+0xd4/0x100
[ 6.707198] ? process_one_work+0x430/0x430
[ 6.708016] ? __kthread_create_on_node+0x180/0x180
[ 6.708909] ret_from_fork+0x21/0x2c
[ 6.709676] ---[ end trace 1a7726d7c3d3c8d0 ]---
[ 5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
[ 5.969672] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
[ 5.971895] scsi 0:0:0:0: Direct-Access Linux scsi_debug 0186 PQ: 0 ANSI: 7
[ 6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.026965] sd 0:0:0:0: [sda] Write Protect is off
[ 6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.546964] sd 0:0:0:0: [sda] Write Protect is off
[ 6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
[ 6.648723] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.649811] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.651418] Workqueue: events_unbound async_run_entry_fn
[ 6.652347] Call Trace:
[ 6.652987] dump_stack+0x79/0xa4
[ 6.653716] kobject_init+0x75/0x90
[ 6.654452] blk_mq_register_dev+0x2a/0x110
[ 6.655269] blk_register_queue+0x7b/0x130
[ 6.656080] device_add_disk+0x1c6/0x460
[ 6.656866] sd_probe_async+0xf1/0x1c0
[ 6.657634] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.658501] async_run_entry_fn+0x30/0x190
[ 6.659311] ? process_one_work+0x12f/0x430
[ 6.660113] process_one_work+0x1aa/0x430
[ 6.660901] ? process_one_work+0x12f/0x430
[ 6.661716] worker_thread+0x1dd/0x470
[ 6.662479] kthread+0xd4/0x100
[ 6.663175] ? process_one_work+0x430/0x430
[ 6.663984] ? __kthread_create_on_node+0x180/0x180
[ 6.664869] ret_from_fork+0x21/0x2c
[ 6.665638] kobject (ffab51ec): tried to init an initialized object, something is seriously wrong.
[ 6.667290] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.668372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.669984] Workqueue: events_unbound async_run_entry_fn
[ 6.670909] Call Trace:
[ 6.671540] dump_stack+0x79/0xa4
[ 6.672266] kobject_init+0x75/0x90
[ 6.673011] blk_mq_register_dev+0x4c/0x110
[ 6.673832] blk_register_queue+0x7b/0x130
[ 6.674633] device_add_disk+0x1c6/0x460
[ 6.675413] sd_probe_async+0xf1/0x1c0
[ 6.676191] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.677057] async_run_entry_fn+0x30/0x190
[ 6.677860] ? process_one_work+0x12f/0x430
[ 6.678667] process_one_work+0x1aa/0x430
[ 6.679455] ? process_one_work+0x12f/0x430
[ 6.680269] worker_thread+0x1dd/0x470
[ 6.681036] kthread+0xd4/0x100
[ 6.681737] ? process_one_work+0x430/0x430
[ 6.682540] ? __kthread_create_on_node+0x180/0x180
[ 6.683420] ret_from_fork+0x21/0x2c
[ 6.684207] ------------[ cut here ]------------
[ 6.685067] WARNING: CPU: 0 PID: 99 at ./include/linux/kref.h:46 kobject_get+0x7f/0x90
[ 6.686592] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.687680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.689280] Workqueue: events_unbound async_run_entry_fn
[ 6.690208] Call Trace:
[ 6.690843] dump_stack+0x79/0xa4
[ 6.691563] __warn+0xd2/0xf0
[ 6.692246] ? kobject_get+0x7f/0x90
[ 6.692992] warn_slowpath_null+0x25/0x30
[ 6.693787] kobject_get+0x7f/0x90
[ 6.694505] kobject_add_internal+0x2e/0x360
[ 6.695322] ? kfree_const+0x18/0x20
[ 6.696071] ? kobject_set_name_vargs+0x62/0x80
[ 6.696914] kobject_add+0x35/0x80
[ 6.697642] blk_mq_register_hctx+0x95/0xc0
[ 6.698447] blk_mq_register_dev+0xc9/0x110
[ 6.699255] blk_register_queue+0x7b/0x130
[ 6.700059] device_add_disk+0x1c6/0x460
[ 6.700849] sd_probe_async+0xf1/0x1c0
[ 6.701628] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.702484] async_run_entry_fn+0x30/0x190
[ 6.703284] ? process_one_work+0x12f/0x430
[ 6.704098] process_one_work+0x1aa/0x430
[ 6.704894] ? process_one_work+0x12f/0x430
[ 6.705704] worker_thread+0x1dd/0x470
[ 6.706488] kthread+0xd4/0x100
[ 6.707198] ? process_one_work+0x430/0x430
[ 6.708016] ? __kthread_create_on_node+0x180/0x180
[ 6.708909] ret_from_fork+0x21/0x2c
[ 6.709676] ---[ end trace 1a7726d7c3d3c8d0 ]---
[ 5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
[ 5.969672] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
[ 5.971895] scsi 0:0:0:0: Direct-Access Linux scsi_debug 0186 PQ: 0 ANSI: 7
[ 6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.026965] sd 0:0:0:0: [sda] Write Protect is off
[ 6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.546964] sd 0:0:0:0: [sda] Write Protect is off
[ 6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
[ 6.648723] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.649811] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.651418] Workqueue: events_unbound async_run_entry_fn
[ 6.652347] Call Trace:
[ 6.652987] dump_stack+0x79/0xa4
[ 6.653716] kobject_init+0x75/0x90
[ 6.654452] blk_mq_register_dev+0x2a/0x110
[ 6.655269] blk_register_queue+0x7b/0x130
[ 6.656080] device_add_disk+0x1c6/0x460
[ 6.656866] sd_probe_async+0xf1/0x1c0
[ 6.657634] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.658501] async_run_entry_fn+0x30/0x190
[ 6.659311] ? process_one_work+0x12f/0x430
[ 6.660113] process_one_work+0x1aa/0x430
[ 6.660901] ? process_one_work+0x12f/0x430
[ 6.661716] worker_thread+0x1dd/0x470
[ 6.662479] kthread+0xd4/0x100
[ 6.663175] ? process_one_work+0x430/0x430
[ 6.663984] ? __kthread_create_on_node+0x180/0x180
[ 6.664869] ret_from_fork+0x21/0x2c
[ 6.665638] kobject (ffab51ec): tried to init an initialized object, something is seriously wrong.
[ 6.667290] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.668372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.669984] Workqueue: events_unbound async_run_entry_fn
[ 6.670909] Call Trace:
[ 6.671540] dump_stack+0x79/0xa4
[ 6.672266] kobject_init+0x75/0x90
[ 6.673011] blk_mq_register_dev+0x4c/0x110
[ 6.673832] blk_register_queue+0x7b/0x130
[ 6.674633] device_add_disk+0x1c6/0x460
[ 6.675413] sd_probe_async+0xf1/0x1c0
[ 6.676191] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.677057] async_run_entry_fn+0x30/0x190
[ 6.677860] ? process_one_work+0x12f/0x430
[ 6.678667] process_one_work+0x1aa/0x430
[ 6.679455] ? process_one_work+0x12f/0x430
[ 6.680269] worker_thread+0x1dd/0x470
[ 6.681036] kthread+0xd4/0x100
[ 6.681737] ? process_one_work+0x430/0x430
[ 6.682540] ? __kthread_create_on_node+0x180/0x180
[ 6.683420] ret_from_fork+0x21/0x2c
[ 6.684207] ------------[ cut here ]------------
[ 6.685067] WARNING: CPU: 0 PID: 99 at ./include/linux/kref.h:46 kobject_get+0x7f/0x90
[ 6.686592] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.687680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.689280] Workqueue: events_unbound async_run_entry_fn
[ 6.690208] Call Trace:
[ 6.690843] dump_stack+0x79/0xa4
[ 6.691563] __warn+0xd2/0xf0
[ 6.692246] ? kobject_get+0x7f/0x90
[ 6.692992] warn_slowpath_null+0x25/0x30
[ 6.693787] kobject_get+0x7f/0x90
[ 6.694505] kobject_add_internal+0x2e/0x360
[ 6.695322] ? kfree_const+0x18/0x20
[ 6.696071] ? kobject_set_name_vargs+0x62/0x80
[ 6.696914] kobject_add+0x35/0x80
[ 6.697642] blk_mq_register_hctx+0x95/0xc0
[ 6.698447] blk_mq_register_dev+0xc9/0x110
[ 6.699255] blk_register_queue+0x7b/0x130
[ 6.700059] device_add_disk+0x1c6/0x460
[ 6.700849] sd_probe_async+0xf1/0x1c0
[ 6.701628] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.702484] async_run_entry_fn+0x30/0x190
[ 6.703284] ? process_one_work+0x12f/0x430
[ 6.704098] process_one_work+0x1aa/0x430
[ 6.704894] ? process_one_work+0x12f/0x430
[ 6.705704] worker_thread+0x1dd/0x470
[ 6.706488] kthread+0xd4/0x100
[ 6.707198] ? process_one_work+0x430/0x430
[ 6.708016] ? __kthread_create_on_node+0x180/0x180
[ 6.708909] ret_from_fork+0x21/0x2c
[ 6.709676] ---[ end trace 1a7726d7c3d3c8d0 ]---
[ 5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
[ 5.969672] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
[ 5.971895] scsi 0:0:0:0: Direct-Access Linux scsi_debug 0186 PQ: 0 ANSI: 7
[ 6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.026965] sd 0:0:0:0: [sda] Write Protect is off
[ 6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.546964] sd 0:0:0:0: [sda] Write Protect is off
[ 6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
[ 6.648723] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.649811] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.651418] Workqueue: events_unbound async_run_entry_fn
[ 6.652347] Call Trace:
[ 6.652987] dump_stack+0x79/0xa4
[ 6.653716] kobject_init+0x75/0x90
[ 6.654452] blk_mq_register_dev+0x2a/0x110
[ 6.655269] blk_register_queue+0x7b/0x130
[ 6.656080] device_add_disk+0x1c6/0x460
[ 6.656866] sd_probe_async+0xf1/0x1c0
[ 6.657634] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.658501] async_run_entry_fn+0x30/0x190
[ 6.659311] ? process_one_work+0x12f/0x430
[ 6.660113] process_one_work+0x1aa/0x430
[ 6.660901] ? process_one_work+0x12f/0x430
[ 6.661716] worker_thread+0x1dd/0x470
[ 6.662479] kthread+0xd4/0x100
[ 6.663175] ? process_one_work+0x430/0x430
[ 6.663984] ? __kthread_create_on_node+0x180/0x180
[ 6.664869] ret_from_fork+0x21/0x2c
[ 6.665638] kobject (ffab51ec): tried to init an initialized object, something is seriously wrong.
[ 6.667290] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.668372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.669984] Workqueue: events_unbound async_run_entry_fn
[ 6.670909] Call Trace:
[ 6.671540] dump_stack+0x79/0xa4
[ 6.672266] kobject_init+0x75/0x90
[ 6.673011] blk_mq_register_dev+0x4c/0x110
[ 6.673832] blk_register_queue+0x7b/0x130
[ 6.674633] device_add_disk+0x1c6/0x460
[ 6.675413] sd_probe_async+0xf1/0x1c0
[ 6.676191] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.677057] async_run_entry_fn+0x30/0x190
[ 6.677860] ? process_one_work+0x12f/0x430
[ 6.678667] process_one_work+0x1aa/0x430
[ 6.679455] ? process_one_work+0x12f/0x430
[ 6.680269] worker_thread+0x1dd/0x470
[ 6.681036] kthread+0xd4/0x100
[ 6.681737] ? process_one_work+0x430/0x430
[ 6.682540] ? __kthread_create_on_node+0x180/0x180
[ 6.683420] ret_from_fork+0x21/0x2c
[ 6.684207] ------------[ cut here ]------------
[ 6.685067] WARNING: CPU: 0 PID: 99 at ./include/linux/kref.h:46 kobject_get+0x7f/0x90
[ 6.686592] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.687680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.689280] Workqueue: events_unbound async_run_entry_fn
[ 6.690208] Call Trace:
[ 6.690843] dump_stack+0x79/0xa4
[ 6.691563] __warn+0xd2/0xf0
[ 6.692246] ? kobject_get+0x7f/0x90
[ 6.692992] warn_slowpath_null+0x25/0x30
[ 6.693787] kobject_get+0x7f/0x90
[ 6.694505] kobject_add_internal+0x2e/0x360
[ 6.695322] ? kfree_const+0x18/0x20
[ 6.696071] ? kobject_set_name_vargs+0x62/0x80
[ 6.696914] kobject_add+0x35/0x80
[ 6.697642] blk_mq_register_hctx+0x95/0xc0
[ 6.698447] blk_mq_register_dev+0xc9/0x110
[ 6.699255] blk_register_queue+0x7b/0x130
[ 6.700059] device_add_disk+0x1c6/0x460
[ 6.700849] sd_probe_async+0xf1/0x1c0
[ 6.701628] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.702484] async_run_entry_fn+0x30/0x190
[ 6.703284] ? process_one_work+0x12f/0x430
[ 6.704098] process_one_work+0x1aa/0x430
[ 6.704894] ? process_one_work+0x12f/0x430
[ 6.705704] worker_thread+0x1dd/0x470
[ 6.706488] kthread+0xd4/0x100
[ 6.707198] ? process_one_work+0x430/0x430
[ 6.708016] ? __kthread_create_on_node+0x180/0x180
[ 6.708909] ret_from_fork+0x21/0x2c
[ 6.709676] ---[ end trace 1a7726d7c3d3c8d0 ]---
csi host0: scsi_debug: version 1.86 [20160430]
[ 5.969672] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
[ 5.971895] scsi 0:0:0:0: Direct-Access Linux scsi_debug 0186 PQ: 0 ANSI: 7
[ 6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.026965] sd 0:0:0:0: [sda] Write Protect is off
[ 6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 6.546964] sd 0:0:0:0: [sda] Write Protect is off
[ 6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[ 6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
[ 6.648723] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.649811] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.651418] Workqueue: events_unbound async_run_entry_fn
[ 6.652347] Call Trace:
[ 6.652987] dump_stack+0x79/0xa4
[ 6.653716] kobject_init+0x75/0x90
[ 6.654452] blk_mq_register_dev+0x2a/0x110
[ 6.655269] blk_register_queue+0x7b/0x130
[ 6.656080] device_add_disk+0x1c6/0x460
[ 6.656866] sd_probe_async+0xf1/0x1c0
[ 6.657634] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.658501] async_run_entry_fn+0x30/0x190
[ 6.659311] ? process_one_work+0x12f/0x430
[ 6.660113] process_one_work+0x1aa/0x430
[ 6.660901] ? process_one_work+0x12f/0x430
[ 6.661716] worker_thread+0x1dd/0x470
[ 6.662479] kthread+0xd4/0x100
[ 6.663175] ? process_one_work+0x430/0x430
[ 6.663984] ? __kthread_create_on_node+0x180/0x180
[ 6.664869] ret_from_fork+0x21/0x2c
[ 6.665638] kobject (ffab51ec): tried to init an initialized object, something is seriously wrong.
[ 6.667290] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.668372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.669984] Workqueue: events_unbound async_run_entry_fn
[ 6.670909] Call Trace:
[ 6.671540] dump_stack+0x79/0xa4
[ 6.672266] kobject_init+0x75/0x90
[ 6.673011] blk_mq_register_dev+0x4c/0x110
[ 6.673832] blk_register_queue+0x7b/0x130
[ 6.674633] device_add_disk+0x1c6/0x460
[ 6.675413] sd_probe_async+0xf1/0x1c0
[ 6.676191] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.677057] async_run_entry_fn+0x30/0x190
[ 6.677860] ? process_one_work+0x12f/0x430
[ 6.678667] process_one_work+0x1aa/0x430
[ 6.679455] ? process_one_work+0x12f/0x430
[ 6.680269] worker_thread+0x1dd/0x470
[ 6.681036] kthread+0xd4/0x100
[ 6.681737] ? process_one_work+0x430/0x430
[ 6.682540] ? __kthread_create_on_node+0x180/0x180
[ 6.683420] ret_from_fork+0x21/0x2c
[ 6.684207] ------------[ cut here ]------------
[ 6.685067] WARNING: CPU: 0 PID: 99 at ./include/linux/kref.h:46 kobject_get+0x7f/0x90
[ 6.686592] CPU: 0 PID: 99 Comm: kworker/u2:1 Not tainted 4.10.0-rc7 #932
[ 6.687680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 6.689280] Workqueue: events_unbound async_run_entry_fn
[ 6.690208] Call Trace:
[ 6.690843] dump_stack+0x79/0xa4
[ 6.691563] __warn+0xd2/0xf0
[ 6.692246] ? kobject_get+0x7f/0x90
[ 6.692992] warn_slowpath_null+0x25/0x30
[ 6.693787] kobject_get+0x7f/0x90
[ 6.694505] kobject_add_internal+0x2e/0x360
[ 6.695322] ? kfree_const+0x18/0x20
[ 6.696071] ? kobject_set_name_vargs+0x62/0x80
[ 6.696914] kobject_add+0x35/0x80
[ 6.697642] blk_mq_register_hctx+0x95/0xc0
[ 6.698447] blk_mq_register_dev+0xc9/0x110
[ 6.699255] blk_register_queue+0x7b/0x130
[ 6.700059] device_add_disk+0x1c6/0x460
[ 6.700849] sd_probe_async+0xf1/0x1c0
[ 6.701628] ? __lock_acquire.isra.14+0x43b/0x940
[ 6.702484] async_run_entry_fn+0x30/0x190
[ 6.703284] ? process_one_work+0x12f/0x430
[ 6.704098] process_one_work+0x1aa/0x430
[ 6.704894] ? process_one_work+0x12f/0x430
[ 6.705704] worker_thread+0x1dd/0x470
[ 6.706488] kthread+0xd4/0x100
[ 6.707198] ? process_one_work+0x430/0x430
[ 6.708016] ? __kthread_create_on_node+0x180/0x180
[ 6.708909] ret_from_fork+0x21/0x2c
[ 6.709676] ---[ end trace 1a7726d7c3d3c8d0 ]---
^ permalink raw reply
* RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements
From: Dexuan Cui @ 2017-02-07 2:23 UTC (permalink / raw)
To: Hannes Reinecke, Bart Van Assche, hare@suse.de, axboe@kernel.dk
Cc: hch@lst.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, jth@kernel.org
In-Reply-To: <MWHPR03MB2669B8A45A07846AF0A06E46BF4F0@MWHPR03MB2669.namprd03.prod.outlook.com>
> From: linux-block-owner@vger.kernel.org [mailto:linux-block-
> owner@vger.kernel.org] On Behalf Of Dexuan Cui
> Sent: Friday, February 3, 2017 20:23
> To: Hannes Reinecke <hare@suse.com>; Bart Van Assche
> <Bart.VanAssche@sandisk.com>; hare@suse.de; axboe@kernel.dk
> Cc: hch@lst.de; linux-kernel@vger.kernel.org; linux-block@vger.kernel.org=
;
> jth@kernel.org
> Subject: RE: [PATCH] genhd: Do not hold event lock when scheduling workqu=
eue
> elements
>=20
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of Hannes Reinecke
> > Sent: Wednesday, February 1, 2017 00:15
> > To: Bart Van Assche <Bart.VanAssche@sandisk.com>; hare@suse.de;
> > axboe@kernel.dk
> > Cc: hch@lst.de; linux-kernel@vger.kernel.org; linux-block@vger.kernel.o=
rg;
> > jth@kernel.org
> > Subject: Re: [PATCH] genhd: Do not hold event lock when scheduling
> workqueue
> > elements
> >
> > On 01/31/2017 01:31 AM, Bart Van Assche wrote:
> > > On Wed, 2017-01-18 at 10:48 +0100, Hannes Reinecke wrote:
> > >> @@ -1488,26 +1487,13 @@ static unsigned long
> > disk_events_poll_jiffies(struct gendisk *disk)
> > >> void disk_block_events(struct gendisk *disk)
> > >> {
> > >> struct disk_events *ev =3D disk->ev;
> > >> - unsigned long flags;
> > >> - bool cancel;
> > >>
> > >> if (!ev)
> > >> return;
> > >>
> > >> - /*
> > >> - * Outer mutex ensures that the first blocker completes canc=
eling
> > >> - * the event work before further blockers are allowed to fin=
ish.
> > >> - */
> > >> - mutex_lock(&ev->block_mutex);
> > >> -
> > >> - spin_lock_irqsave(&ev->lock, flags);
> > >> - cancel =3D !ev->block++;
> > >> - spin_unlock_irqrestore(&ev->lock, flags);
> > >> -
> > >> - if (cancel)
> > >> + if (atomic_inc_return(&ev->block) =3D=3D 1)
> > >> cancel_delayed_work_sync(&disk->ev->dwork);
> > >>
> > >> - mutex_unlock(&ev->block_mutex);
> > >> }
> > >
> > > Hello Hannes,
> > >
> > > I have already encountered a few times a deadlock that was caused by =
the
> > > event checking code so I agree with you that it would be a big step f=
orward
> > > if such deadlocks wouldn't occur anymore. However, this patch realize=
s a
> > > change that has not been described in the patch description, namely t=
hat
> > > disk_block_events() calls are no longer serialized. Are you sure it i=
s safe
> > > to drop the serialization of disk_block_events() calls?
> > >
> > Well, this whole synchronization stuff it a bit weird; I so totally fai=
l
> > to see the rationale for it.
> > But anyway, once we've converted ev->block to atomics I _think_ the
> > mutex_lock can remain; will be checking.
> >
> > Cheers,
> >
> > Hannes
> > --
>=20
> Hi, I think I got the same calltrace with today's linux-next (next-201702=
03).
>=20
> The issue happened every time when my Linux virtual machine booted and
> Hannes's patch could NOT help.
>=20
> The calltrace is pasted below.
>=20
> -- Dexuan
=20
Any news on this thread?
The issue is still blocking Linux from booting up normally in my test. :-(
Have we identified the faulty patch?
If so, at least I can try to revert it to boot up.
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements
From: Bart Van Assche @ 2017-02-07 2:56 UTC (permalink / raw)
To: decui@microsoft.com, hare@suse.com, hare@suse.de, axboe@kernel.dk
Cc: hch@lst.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, jth@kernel.org
In-Reply-To: <MWHPR03MB26699D4657FB67A535972208BF430@MWHPR03MB2669.namprd03.prod.outlook.com>
T24gVHVlLCAyMDE3LTAyLTA3IGF0IDAyOjIzICswMDAwLCBEZXh1YW4gQ3VpIHdyb3RlOg0KPiBB
bnkgbmV3cyBvbiB0aGlzIHRocmVhZD8NCj4gDQo+IFRoZSBpc3N1ZSBpcyBzdGlsbCBibG9ja2lu
ZyBMaW51eCBmcm9tIGJvb3RpbmcgdXAgbm9ybWFsbHkgaW4gbXkgdGVzdC4gOi0oDQo+IA0KPiBI
YXZlIHdlIGlkZW50aWZpZWQgdGhlIGZhdWx0eSBwYXRjaD8NCj4gSWYgc28sIGF0IGxlYXN0IEkg
Y2FuIHRyeSB0byByZXZlcnQgaXQgdG8gYm9vdCB1cC4NCg0KSXQncyBpbnRlcmVzdGluZyB0aGF0
IHlvdSBoYXZlIGEgcmVwcm9kdWNpYmxlIHRlc3RjYXNlLiBJZiB5b3UgY2FuIHRlbGwgbWUgaG93
IHRvDQpyZXByb2R1Y2UgdGhpcyBJJ2xsIGhhdmUgYSBsb29rIGF0IGl0IHRvZ2V0aGVyIHdpdGgg
SGFubmVzLg0KDQpCYXJ0LgpXZXN0ZXJuIERpZ2l0YWwgQ29ycG9yYXRpb24gKGFuZCBpdHMgc3Vi
c2lkaWFyaWVzKSBFLW1haWwgQ29uZmlkZW50aWFsaXR5IE5vdGljZSAmIERpc2NsYWltZXI6CgpU
aGlzIGUtbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgbWF5IGNvbnRhaW4g
Y29uZmlkZW50aWFsIG9yIGxlZ2FsbHkgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBvZiBXREMgYW5k
L29yIGl0cyBhZmZpbGlhdGVzLCBhbmQgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv
ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkLiBJ
ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgY29w
eWluZywgZGlzdHJpYnV0aW9uIG9yIGFueSBhY3Rpb24gdGFrZW4gb3Igb21pdHRlZCB0byBiZSB0
YWtlbiBpbiByZWxpYW5jZSBvbiBpdCwgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh
dGVseSBhbmQgZGVsZXRlIHRoZSBlLW1haWwgaW4gaXRzIGVudGlyZXR5IGZyb20geW91ciBzeXN0
ZW0uCg==
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox