From patchwork Sat Mar 3 01:54:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "jianchao.wang" X-Patchwork-Id: 10255931 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A4BAD60211 for ; Sat, 3 Mar 2018 01:54:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 95FCB2860C for ; Sat, 3 Mar 2018 01:54:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8A7F928609; Sat, 3 Mar 2018 01:54:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 36C4228609 for ; Sat, 3 Mar 2018 01:54:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965098AbeCCBx7 (ORCPT ); Fri, 2 Mar 2018 20:53:59 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:42122 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965064AbeCCBx6 (ORCPT ); Fri, 2 Mar 2018 20:53:58 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w231mxba047855; Sat, 3 Mar 2018 01:53:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=F1VFdq01xGVorcMZez9lA/nJSNU+Few5QOfM8txlzpU=; b=GfJfPUaQgEEOb40wkKBVwr7wMDW9deIVwLWUCZuqT1U/oLFRFQHAHarmEJKL6VxywUh6 wgXmVIyxUxjOfcnRPsY40RUnyIFuqoOkZ0TS5gzRKihaE7O680D4Wa8UI7gZMlIr8Ob6 UEGPVpBFjQx8X244YbFPxt7fabNkO/4D/yMaLgoOfzyVzqerpvwHuIsN541CA4vfkhPI gQiCqGzOe/OBlACgm5Kp61LlW08ygeSLz840Ut5VxfgOPILWQNFs16a6BVy68YJy3KPS reQBnU4FzWhqNCVkfTB4Eil+l6gkMrhq3sXc0IDNA28aJT03weQKmYWMAnP57u1eRQul Jg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2gfh4s056d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Mar 2018 01:53:54 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w231rptJ022527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Mar 2018 01:53:52 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w231rosk007725; Sat, 3 Mar 2018 01:53:51 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.70.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Mar 2018 17:53:50 -0800 From: Jianchao Wang To: jejb@linux.vnet.ibm.com, martin.petersen@oracle.com Cc: Bart.VanAssche@wdc.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig Subject: [PATCH V4] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert Date: Sat, 3 Mar 2018 09:54:09 +0800 Message-Id: <1520042049-8874-1-git-send-email-jianchao.w.wang@oracle.com> X-Mailer: git-send-email 2.7.4 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8820 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803030017 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In scsi core, __scsi_queue_insert should just put request back on the queue and retry using the same command as before. However, for blk-mq, scsi_mq_requeue_cmd is employed here which will unprepare the request. To align with the semantics of __scsi_queue_insert, use blk_mq_requeue_request with kick_requeue_list == true and put the reference of scsi_device. Cc: Christoph Hellwig Signed-off-by: Jianchao Wang Reviewed-by: Bart Van Assche --- Changelog: V3 -> V4: - modify the comment and make it more clearly V2 -> V3: - add comment to explain why we need a put_device in __scsi_queue_insert - add reviewed-by V1 -> V2: - add put_device on scsi_device->sdev_gendev drivers/scsi/scsi_lib.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index a86df9c..6ce33f6 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -191,7 +191,19 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd, int reason, bool unbusy) */ cmd->result = 0; if (q->mq_ops) { - scsi_mq_requeue_cmd(cmd); + /* + * Before a SCSI command is dispatched, + * get_device(&sdev->sdev_gendev) is called and the host, + * target and device busy counters are increased. Since + * requeuing a request causes these actions to be repeated and + * since scsi_device_unbusy() has already been called, + * put_device(&device->sdev_gendev) must still be called. Call + * put_device() after blk_mq_requeue_request() to avoid that + * removal of the SCSI device can start before requeueing has + * happened. + */ + blk_mq_requeue_request(cmd->request, true); + put_device(&device->sdev_gendev); return; } spin_lock_irqsave(q->queue_lock, flags);