From patchwork Fri Mar 2 03:31:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "jianchao.wang" X-Patchwork-Id: 10253165 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 A055260291 for ; Fri, 2 Mar 2018 03:31:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 902A7287A3 for ; Fri, 2 Mar 2018 03:31:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 84D83287AB; Fri, 2 Mar 2018 03:31:31 +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 3D9DC287A3 for ; Fri, 2 Mar 2018 03:31:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1164604AbeCBDbQ (ORCPT ); Thu, 1 Mar 2018 22:31:16 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:57062 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1163935AbeCBDbP (ORCPT ); Thu, 1 Mar 2018 22:31:15 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w223R2CV014573; Fri, 2 Mar 2018 03:31:11 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=1dlzblFVik6anl1Lx3cAlngisWtzYveQtNlp8kCuG2w=; b=t6jgnziKYPXc0zNd2V0cmLBBpRgs/epzWkzkj3HF/6dlz/3B6SK61QhfHY+W26k8uXP5 b7FJ8gpMpohp3rG/ktRHEQX43N3TCmafZcDVeXlo9jsg7MLtPfC1sfHI8ygPCOhzW6N8 BcJhwUJwu6OjhlFaPq85LQL9vz4hyjkYwTjcEBrMoMBY2llwVuG1GXOKmPA+dUvfpClJ Ts7pTL9WeFkyd95bCSedvLoMOzLpFvyJ73U8/AJPGKiRbUHKtRtTHUIhzCXTD/w9NF0u vZeCNkEJqNND6vzrPbs/nRv134s5Od2EsQc1HMIUR4eFlojNfnF/99D79a7AB0qy873w yQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2gewyb83fd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Mar 2018 03:31:11 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w223VAjw016206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 2 Mar 2018 03:31:10 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w223V9Pc016654; Fri, 2 Mar 2018 03:31:09 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.70.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Mar 2018 19:31:08 -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 V3] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert Date: Fri, 2 Mar 2018 11:31:14 +0800 Message-Id: <1519961474-15236-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=8819 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-1803020036 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: V2 -> V3: - add commit 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 | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index a86df9c..d2f1838 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -191,7 +191,13 @@ 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); + /* + * scsi_device.sdev_gendev will be get every time in .get_budget and + * be put in scsi_end_request. Hence we need to put the reference + * here when we decide to requeue request. + */ + blk_mq_requeue_request(cmd->request, true); + put_device(&device->sdev_gendev); return; } spin_lock_irqsave(q->queue_lock, flags);