From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751719AbcGUI3Q (ORCPT ); Thu, 21 Jul 2016 04:29:16 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:63066 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751213AbcGUI3O (ORCPT ); Thu, 21 Jul 2016 04:29:14 -0400 X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="374487474" Date: Thu, 21 Jul 2016 10:29:13 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Bob Liu CC: , , , Subject: Re: [PATCH 2/3] xen-blkfront: introduce blkif_set_queue_limits() Message-ID: <20160721082913.ahsy5a63ymfoymqv@mac> References: <1468575109-12209-1-git-send-email-bob.liu@oracle.com> <1468575109-12209-2-git-send-email-bob.liu@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1468575109-12209-2-git-send-email-bob.liu@oracle.com> User-Agent: Mutt/1.6.2-neo (2016-06-11) X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 15, 2016 at 05:31:48PM +0800, Bob Liu wrote: > blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not > as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits > with initial correct values. Hm, great, and as usual in Linux there isn't even a comment in the function that explains what it is supposed to do, or what are the side-effects of calling blk_mq_update_nr_hw_queues. > Signed-off-by: Bob Liu > > drivers/block/xen-blkfront.c | 91 ++++++++++++++++++++++++-------------------- > 1 file changed, 50 insertions(+), 41 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 032fc94..10f46a8 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -189,6 +189,8 @@ struct blkfront_info > struct mutex mutex; > struct xenbus_device *xbdev; > struct gendisk *gd; > + u16 sector_size; > + unsigned int physical_sector_size; > int vdevice; > blkif_vdev_t handle; > enum blkif_state connected; > @@ -913,9 +915,45 @@ static struct blk_mq_ops blkfront_mq_ops = { > .map_queue = blk_mq_map_queue, > }; > > +static void blkif_set_queue_limits(struct blkfront_info *info) > +{ > + struct request_queue *rq = info->rq; > + struct gendisk *gd = info->gd; > + unsigned int segments = info->max_indirect_segments ? : > + BLKIF_MAX_SEGMENTS_PER_REQUEST; > + > + queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq); > + > + if (info->feature_discard) { > + queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, rq); > + blk_queue_max_discard_sectors(rq, get_capacity(gd)); > + rq->limits.discard_granularity = info->discard_granularity; > + rq->limits.discard_alignment = info->discard_alignment; > + if (info->feature_secdiscard) > + queue_flag_set_unlocked(QUEUE_FLAG_SECDISCARD, rq); > + } AFAICT, at the point this function is called (in blkfront_resume), the value of info->feature_discard is still from the old backend, maybe this should be called from blkif_recover after blkfront_gather_backend_features? Roger.