From patchwork Mon Feb 22 09:51:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Junichi Nomura X-Patchwork-Id: 8374401 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B1C569F314 for ; Mon, 22 Feb 2016 09:53:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CF57020220 for ; Mon, 22 Feb 2016 09:53:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 20E872037C for ; Mon, 22 Feb 2016 09:53:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753093AbcBVJxV (ORCPT ); Mon, 22 Feb 2016 04:53:21 -0500 Received: from TYO202.gate.nec.co.jp ([210.143.35.52]:55879 "EHLO tyo202.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752037AbcBVJxU convert rfc822-to-8bit (ORCPT ); Mon, 22 Feb 2016 04:53:20 -0500 Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id u1M9rCWS018272; Mon, 22 Feb 2016 18:53:12 +0900 (JST) Received: from mailsv.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id u1M9rBj22739; Mon, 22 Feb 2016 18:53:11 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id u1M9rB7r015683; Mon, 22 Feb 2016 18:53:11 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.136] [10.38.151.136]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-5696820; Mon, 22 Feb 2016 18:51:30 +0900 Received: from BPXM12GP.gisp.nec.co.jp ([10.38.151.204]) by BPXC08GP.gisp.nec.co.jp ([10.38.151.136]) with mapi id 14.03.0224.002; Mon, 22 Feb 2016 18:51:30 +0900 From: Junichi Nomura To: Mike Snitzer CC: device-mapper development , linux-scsi , Hannes Reinecke Subject: Re: dm-multipath test scripts Thread-Topic: dm-multipath test scripts Thread-Index: AQHRanBKUqtLlSz/RUCjLYVPGcKDg58x7qqAgACHMgCAALmqgIAAsCmAgANhwwA= Date: Mon, 22 Feb 2016 09:51:28 +0000 Message-ID: <56CADA20.7050209@ce.jp.nec.com> References: <20151007053923.GA10749@xzibit.linux.bs1.fc.nec.co.jp> <20160218171745.GA15071@redhat.com> <56C662F1.8070407@ce.jp.nec.com> <56C6D45A.6060407@ce.jp.nec.com> <20160219194216.GB21133@redhat.com> <20160220061247.GA23333@redhat.com> In-Reply-To: <20160220061247.GA23333@redhat.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.125.85] Content-ID: MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 02/20/16 15:12, Mike Snitzer wrote: > On Fri, Feb 19 2016 at 2:42pm -0500, Mike Snitzer wrote: >> Have you been running with blk-mq? >> Either by setting CONFIG_DM_MQ_DEFAULT or: >> echo Y > /sys/module/dm_mod/parameters/use_blk_mq >> >> I'm seeing test_02_sdev_delete fail with blk-mq enabled. > > I only see failure if I stack dm-mq ontop of old non-mq scsi devices with: > > echo N > /sys/module/scsi_mod/parameters/use_blk_mq > echo Y > /sys/module/dm_mod/parameters/use_blk_mq Ah, I didn't test that combination. I can see the failure, too. > But this makes me think the novelty of having dm-mq support stacking on > non-blk-mq devices was misplaced. It is a senseless config. I'll > probably remove support for such stacking soon (next week). Looking at the failure, I suspect it could be a common issue of dm-mq regardless of underlying device type. When requeueing, following calls happen in dm-mq: dm_requeue_original_request() { .. blk_mq_requeue_request(rq); blk_mq_kick_requeue_list(rq->q); then from block workqueue: blk_mq_requeue_work() { .. blk_mq_start_hw_queue(q); and blk_mq_start_hw_queue() re-starts the queue even if DM has stopped it for suspending. As a result, dm-mq ends up repeating submit-error-requeue forever and suspend never completes. Or, suspend somehow proceeds to clear DMF_NOFLUSH_SUSPENDING and I/O error may directly be returned to submitter. Attached patch fixes the problem for DM. But given the code comment, there should be call sites which depend on 'start-if-stopped' behavior of blk_mq_requeue_work and we may need other solution. diff --git a/block/blk-mq.c b/block/blk-mq.c index 56c0a72..bbfe936 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -481,11 +481,7 @@ static void blk_mq_requeue_work(struct work_struct *work) blk_mq_insert_request(rq, false, false, false); } - /* - * Use the start variant of queue running here, so that running - * the requeue work will kick stopped queues. - */ - blk_mq_start_hw_queues(q); + blk_mq_run_hw_queues(q, false); } void blk_mq_add_to_requeue_list(struct request *rq, bool at_head)--