Patch "xen-blkfront: fix resume issues after a migration" has been added to the 4.6-stable tree
Subsystems (4)
This is a note to let you know that I've just added the patch titled
xen-blkfront: fix resume issues after a migration
to the 4.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-blkfront-fix-resume-issues-after-a-migration.patch
and it can be found in the queue-4.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
2a6f71ad99cabe436e70c3f5fcf58072cb3bc07fMon Sep 17 00:00:00 2001
From: Bob Liu <[email protected]>
Date: Tue, 31 May 2016 16:59:17 +0800
Subject: xen-blkfront: fix resume issues after a migration
From: Bob Liu <[email protected]>
commit 2a6f71ad99cabe436e70c3f5fcf58072cb3bc07f upstream.
After a migrate to another host (which may not have multiqueue support), the number of rings (block hardware queues)
may be changed and the ring info structure will also be reallocated.
This patch fixes two related bugs:
* call blk_mq_update_nr_hw_queues() to make blk-core know the number of hardware queues have been changed.
* Don't store rinfo pointer to hctx->driver_data, because rinfo may be reallocated so use hctx->queue_num to get the rinfo structure instead.
--- drivers/block/xen-blkfront.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-)
drivers/block/xen-blkfront.c +8 -12
@@ -877,8 +877,12 @@ static int blkif_queue_rq(struct blk_mq_ const struct blk_mq_queue_data *qd) {unsigned long flags; -struct blkfront_ring_info *rinfo = (struct blkfront_ring_info *)hctx->driver_data; +int qid = hctx->queue_num; +struct blkfront_info *info = hctx->queue->queuedata; +struct blkfront_ring_info *rinfo =NULL ; +BUG_ON (info->nr_rings <= qid); + rinfo = &info->rinfo[qid];blk_mq_start_request (qd->rq);spin_lock_irqsave (&rinfo->ring_lock, flags);if (RING_FULL (&rinfo->ring))
@@ -904,20 +908,9 @@ out_busy:return BLK_MQ_RQ_QUEUE_BUSY ; } -static int blk_mq_init_hctx (struct blk_mq_hw_ctx *hctx,void *data, -unsigned int index) -{ -struct blkfront_info *info = (struct blkfront_info *)data; - -BUG_ON (info->nr_rings <= index); - hctx->driver_data = &info->rinfo[index]; -return 0 ; -} -static struct blk_mq_ops blkfront_mq_ops = { .queue_rq = blkif_queue_rq, .map_queue = blk_mq_map_queue, - .init_hctx = blk_mq_init_hctx, }; static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
@@ -953,6 +946,7 @@ static int xlvbd_init_blk_queue(struct greturn PTR_ERR (rq); } + rq->queuedata = info;queue_flag_set_unlocked (QUEUE_FLAG_VIRT , rq);if (info->feature_discard) {
@@ -2137,6 +2131,8 @@ static int blkfront_resume(struct xenbusreturn err; err =talk_to_blkback (dev, info); +if (!err) +blk_mq_update_nr_hw_queues (&info->tag_set, info->nr_rings);/* * We have to wait for the backend to switch to
Patches currently in stable-queue which might be from [email protected] are
queue-4.6/xen-blkfront-don-t-call-talk_to_blkback-when-already-connected-to-blkback.patch queue-4.6/xen-blkfront-save-uncompleted-reqs-in-blkfront_resume.patch queue-4.6/xen-blkfront-fix-resume-issues-after-a-migration.patch