From patchwork Mon Jun 17 15:18:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 10999485 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E7C9D924 for ; Mon, 17 Jun 2019 15:18:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D47E02872F for ; Mon, 17 Jun 2019 15:18:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C84EE2882F; Mon, 17 Jun 2019 15:18:30 +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.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham 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 54BC12872F for ; Mon, 17 Jun 2019 15:18:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728269AbfFQPSa (ORCPT ); Mon, 17 Jun 2019 11:18:30 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:34487 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726731AbfFQPS3 (ORCPT ); Mon, 17 Jun 2019 11:18:29 -0400 Received: by mail-pf1-f193.google.com with SMTP id c85so5872341pfc.1 for ; Mon, 17 Jun 2019 08:18:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=56VzP6loyvCbiQA6Sh4850/nEbd1cCME9gjuek5ksrc=; b=NzR0ulDWQH+xNg07zA55xlxtvFPyrUMw+2PCcjCsn14SA3isVrnSxJUnWSSrgy+Zet UhmwG43DexdJ4tUwTX/tUScIdbAXqhHNtGMh3QURTq8zQlH/wI5jHNnadU0lyIvkEpXQ C1sd+mYEiN/okKucvcPJfipWr7aprTOmOG9GUvDBUoshFZp0V5e446TGXbOFY6fj3rxJ VijNvqPsaXEefIy+vYBaSjgrd7oGCVUOtPsamsVHXwuhhZl/QzIY/GVUycjXCB+k09Hd 8j9ciyuqSrmixEJHtL6V9x7IYSbjbeagK18IUacdJ52qpRy1fqwDMyM8g7plqSQE/7gc AQaw== X-Gm-Message-State: APjAAAXG/PK52G5YaeyGUWNxQFwu5pOMBA651k7fo4dxZIPk/oG4RKHt MS41kWFqV2SW+0sVYXQUP5Y= X-Google-Smtp-Source: APXvYqwGuRuMYq/SRxvIpmUFJhHrUy9erW1Z+DAiFN44z8aTJhurnO5Qe+1WfPN/sWIGbSvHfLvH1w== X-Received: by 2002:aa7:8f2c:: with SMTP id y12mr30583816pfr.38.1560784709094; Mon, 17 Jun 2019 08:18:29 -0700 (PDT) Received: from desktop-bart.svl.corp.google.com ([2620:15c:2cd:202:4308:52a3:24b6:2c60]) by smtp.gmail.com with ESMTPSA id n5sm12529949pgd.26.2019.06.17.08.18.27 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 17 Jun 2019 08:18:28 -0700 (PDT) From: Bart Van Assche To: "Martin K . Petersen" , "James E . J . Bottomley" Cc: linux-scsi@vger.kernel.org, Christoph Hellwig , Ming Lei , Hannes Reinecke , Johannes Thumshirn , Bart Van Assche , Hannes Reinecke , James Smart , "Ewan D . Milne" , Laurence Oberman Subject: [PATCH v4 1/3] scsi: Restrict user space SCSI device state changes to "running" and "offfline" Date: Mon, 17 Jun 2019 08:18:18 -0700 Message-Id: <20190617151820.241583-2-bvanassche@acm.org> X-Mailer: git-send-email 2.20.GIT In-Reply-To: <20190617151820.241583-1-bvanassche@acm.org> References: <20190617151820.241583-1-bvanassche@acm.org> MIME-Version: 1.0 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 The ability to modify the SCSI device state was introduced by commit 638127e579a4 ("[PATCH] Fix error handler offline behaviour"; v2.6.12). That same commit introduced the following device states: { SDEV_CREATED, "created" }, { SDEV_RUNNING, "running" }, { SDEV_CANCEL, "cancel" }, { SDEV_DEL, "deleted" }, { SDEV_QUIESCE, "quiesce" }, { SDEV_OFFLINE, "offline" }, The SDEV_BLOCK state was introduced later to avoid that an FC cable pull would immediately result in an I/O error (commit 1094e682310e; "[PATCH] suspending I/Os to a device"; v2.6.12). That same patch introduced the ability to set the SDEV_BLOCK state from user space. I'm not sure whether that ability was introduced on purpose or accidentally. Since there is agreement that only writing "running" or "offline" into the SCSI sysfs device state attribute makes sense, restrict sysfs writes to these values. This patch makes sure that SDEV_BLOCK is only used for its original purpose, namely to allow transport drivers and LLDs to block further .queuecommand() calls while transport layer or adapter recovery is in progress. Note: a web search for "/sys/class/scsi_device" AND "device/state" revealed several storage configuration guides. The instructions I found in these guides tell users to write the value "running" or "offline" in the SCSI device state sysfs attribute and no other values. Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: Johannes Thumshirn Cc: James Smart Cc: Ewan D. Milne Cc: Laurence Oberman Signed-off-by: Bart Van Assche Reviewed-by: Hannes Reinecke --- drivers/scsi/scsi_sysfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 3b119ca0cc0c..850cdc731a1f 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -766,8 +766,13 @@ store_state_field(struct device *dev, struct device_attribute *attr, break; } } - if (!state) + switch (state) { + case SDEV_RUNNING: + case SDEV_OFFLINE: + break; + default: return -EINVAL; + } mutex_lock(&sdev->state_mutex); ret = scsi_device_set_state(sdev, state); From patchwork Mon Jun 17 15:18:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 10999487 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 444581398 for ; Mon, 17 Jun 2019 15:18:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 335052882D for ; Mon, 17 Jun 2019 15:18:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 27A6428837; Mon, 17 Jun 2019 15:18:32 +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.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham 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 AE9D92882D for ; Mon, 17 Jun 2019 15:18:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728322AbfFQPSb (ORCPT ); Mon, 17 Jun 2019 11:18:31 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:32931 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726731AbfFQPSb (ORCPT ); Mon, 17 Jun 2019 11:18:31 -0400 Received: by mail-pf1-f196.google.com with SMTP id x15so5876265pfq.0 for ; Mon, 17 Jun 2019 08:18:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=g+MKUUj69ETXmnzh4N6h+VZvivosQHlAwM0q9HI0Gwo=; b=aKj4LgOHwbCw01kuGr0h5fdaQx8BKgNmhqXbHchEL5ToMD+NM6JllU751kjWechC69 9ZbCrmdZJvVI9G8vQGhh8RmNqLwo/FShGm0/om/BI84nHktFTfp6IYt3JfMGXalcll0p pe55GPp3/mgtDZ860skK2MsS6YndIwdqWlzhHD26TweQKZm1TTS8fAqqxluYZDsWUdpj Gzzm+Hu4kkp13ZDNKXJ327IJzU/Kn1TYfsqqYLJKAV6TblDNjpuT266JLwYeGwhpvIev MCrGElk/UTpgdMh63gy7/ZNKml0FEER90/3SSJQE7AtGRAH/upOhNYsVzYZSTHv71aM1 buJQ== X-Gm-Message-State: APjAAAWeuw+iXrFkAJXfctczPmgVat0nGsqdf2irdEu2v3yPr4R4u5Ey eIRgLT6Dl+LBZRzdJ6W6jjo= X-Google-Smtp-Source: APXvYqwsvjO/rAFItUBZKgMd/TIJPIpNJ9HiOLy30Jk94lc7JsxIMzv6EnKLE6Oj6ByL45d0R3G4jw== X-Received: by 2002:aa7:8c0f:: with SMTP id c15mr88074948pfd.113.1560784710463; Mon, 17 Jun 2019 08:18:30 -0700 (PDT) Received: from desktop-bart.svl.corp.google.com ([2620:15c:2cd:202:4308:52a3:24b6:2c60]) by smtp.gmail.com with ESMTPSA id n5sm12529949pgd.26.2019.06.17.08.18.29 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 17 Jun 2019 08:18:29 -0700 (PDT) From: Bart Van Assche To: "Martin K . Petersen" , "James E . J . Bottomley" Cc: linux-scsi@vger.kernel.org, Christoph Hellwig , Ming Lei , Hannes Reinecke , Johannes Thumshirn , Bart Van Assche , Hannes Reinecke Subject: [PATCH v4 2/3] scsi: Avoid that .queuecommand() gets called for a blocked SCSI device Date: Mon, 17 Jun 2019 08:18:19 -0700 Message-Id: <20190617151820.241583-3-bvanassche@acm.org> X-Mailer: git-send-email 2.20.GIT In-Reply-To: <20190617151820.241583-1-bvanassche@acm.org> References: <20190617151820.241583-1-bvanassche@acm.org> MIME-Version: 1.0 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 Several SCSI transport and LLD drivers surround code that does not tolerate concurrent calls of .queuecommand() with scsi_target_block() / scsi_target_unblock(). These last two functions use blk_mq_quiesce_queue() / blk_mq_unquiesce_queue() for scsi-mq request queues to prevent concurrent .queuecommand() calls. However, that is not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd(). Hence surround the .queuecommand() call from the SCSI error handler with code that avoids that .queuecommand() gets called in the blocked state. Note: converting the .queuecommand() call in scsi_send_eh_cmnd() into code that calls blk_get_request() + blk_execute_rq() is not an option since scsi_send_eh_cmnd() must be able to make forward progress even if all requests have been allocated. Reviewed-by: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: Johannes Thumshirn Signed-off-by: Bart Van Assche Reviewed-by: Hannes Reinecke --- drivers/scsi/scsi_error.c | 26 ++++++++++++++++++++++++-- drivers/scsi/scsi_lib.c | 4 ---- 2 files changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 8e9680572b9f..d516dd1b824d 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -1054,7 +1054,7 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd, struct scsi_device *sdev = scmd->device; struct Scsi_Host *shost = sdev->host; DECLARE_COMPLETION_ONSTACK(done); - unsigned long timeleft = timeout; + unsigned long timeleft = timeout, delay; struct scsi_eh_save ses; const unsigned long stall_for = msecs_to_jiffies(100); int rtn; @@ -1065,7 +1065,29 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd, scsi_log_send(scmd); scmd->scsi_done = scsi_eh_done; - rtn = shost->hostt->queuecommand(shost, scmd); + + /* + * Lock sdev->state_mutex to avoid that scsi_device_quiesce() can + * change the SCSI device state after we have examined it and before + * .queuecommand() is called. + */ + mutex_lock(&sdev->state_mutex); + while (sdev->sdev_state == SDEV_BLOCK && timeleft > 0) { + mutex_unlock(&sdev->state_mutex); + SCSI_LOG_ERROR_RECOVERY(5, sdev_printk(KERN_DEBUG, sdev, + "%s: state %d <> %d\n", __func__, sdev->sdev_state, + SDEV_BLOCK)); + delay = min(timeleft, stall_for); + timeleft -= delay; + msleep(jiffies_to_msecs(delay)); + mutex_lock(&sdev->state_mutex); + } + if (sdev->sdev_state != SDEV_BLOCK) + rtn = shost->hostt->queuecommand(shost, scmd); + else + rtn = SCSI_MLQUEUE_DEVICE_BUSY; + mutex_unlock(&sdev->state_mutex); + if (rtn) { if (timeleft > stall_for) { scsi_eh_restore_cmnd(scmd, &ses); diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index b4a63e4fcf73..ec5b4b5bc011 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -2632,10 +2632,6 @@ EXPORT_SYMBOL_GPL(scsi_internal_device_block_nowait); * a legal transition). When the device is in this state, command processing * is paused until the device leaves the SDEV_BLOCK state. See also * scsi_internal_device_unblock(). - * - * To do: avoid that scsi_send_eh_cmnd() calls queuecommand() after - * scsi_internal_device_block() has blocked a SCSI device and also - * remove the rport mutex lock and unlock calls from srp_queuecommand(). */ static int scsi_internal_device_block(struct scsi_device *sdev) { From patchwork Mon Jun 17 15:18:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 10999489 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D46821398 for ; Mon, 17 Jun 2019 15:18:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C3D602872F for ; Mon, 17 Jun 2019 15:18:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B82392882F; Mon, 17 Jun 2019 15:18:33 +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.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham 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 42CED2872F for ; Mon, 17 Jun 2019 15:18:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728390AbfFQPSd (ORCPT ); Mon, 17 Jun 2019 11:18:33 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:35502 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726731AbfFQPSc (ORCPT ); Mon, 17 Jun 2019 11:18:32 -0400 Received: by mail-pf1-f196.google.com with SMTP id d126so5866556pfd.2 for ; Mon, 17 Jun 2019 08:18:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CsnxCpD5pGX+zHARFTc2bFyrGv0dNr5vaju+kWZ+mfs=; b=HOzganM3V/Pz2fKArSQcRRrjW03MT8rqN7f0th/sv1GQ3uhXSgnhoSpoAdoiDuu0Ty 36sbsQOrXroeeErseFS1scQdP2G61LezlAxciuQ1u4N+X0owNA2CocYN0qvCv3gvk1fq 0UU7mAOtJP5fO/OlzOxciNn94vuUQnRAIH+lmiJToeGto14yBKVhraIJOLWXPU8usyme sZmf0sjnyJUMVkiUQkYlQm3fRD82aSxv4aDv5Wz3AuXPtUpDfQQ88OXBeulHRszVB6+8 i+AIL5hEqK3VWlgRSQI41aR75YEYQIHzhhLzxRcVd14tlhWpw+FSian5KbKjXgPkt78l Okkw== X-Gm-Message-State: APjAAAW+vlIglKW9q6MvktDc1L6C4qnSnSKf7SL0YDD4vbOXgVPki9A7 w4TnxIlJynvO6Of6cO0yxck= X-Google-Smtp-Source: APXvYqxJ2IUudiiaM04BPTkPilE6PfBPR4KbDK+6xosfohTFi1z3zECLZE7i7pR+EJ5GuBwOk5kXvw== X-Received: by 2002:a63:a514:: with SMTP id n20mr20131078pgf.438.1560784711962; Mon, 17 Jun 2019 08:18:31 -0700 (PDT) Received: from desktop-bart.svl.corp.google.com ([2620:15c:2cd:202:4308:52a3:24b6:2c60]) by smtp.gmail.com with ESMTPSA id n5sm12529949pgd.26.2019.06.17.08.18.30 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 17 Jun 2019 08:18:31 -0700 (PDT) From: Bart Van Assche To: "Martin K . Petersen" , "James E . J . Bottomley" Cc: linux-scsi@vger.kernel.org, Christoph Hellwig , Ming Lei , Hannes Reinecke , Johannes Thumshirn , Bart Van Assche , Laurence Oberman , Jason Gunthorpe , Leon Romanovsky , Doug Ledford Subject: [PATCH v4 3/3] RDMA/srp: Fix a sleep-in-invalid-context bug Date: Mon, 17 Jun 2019 08:18:20 -0700 Message-Id: <20190617151820.241583-4-bvanassche@acm.org> X-Mailer: git-send-email 2.20.GIT In-Reply-To: <20190617151820.241583-1-bvanassche@acm.org> References: <20190617151820.241583-1-bvanassche@acm.org> MIME-Version: 1.0 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 The previous patch guarantees that srp_queuecommand() does not get invoked while reconnecting occurs. Hence remove the code from srp_queuecommand() that prevents command queueing while reconnecting. This patch avoids that the following can appear in the kernel log: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 0, pid: 5600, name: scsi_eh_9 1 lock held by scsi_eh_9/5600: #0: (rcu_read_lock){....}, at: [<00000000cbb798c7>] __blk_mq_run_hw_queue+0xf1/0x1e0 Preemption disabled at: [<00000000139badf2>] __blk_mq_delay_run_hw_queue+0x78/0xf0 CPU: 9 PID: 5600 Comm: scsi_eh_9 Tainted: G W 4.15.0-rc4-dbg+ #1 Hardware name: Dell Inc. PowerEdge R720/0VWT90, BIOS 2.5.4 01/22/2016 Call Trace: dump_stack+0x67/0x99 ___might_sleep+0x16a/0x250 [ib_srp] __mutex_lock+0x46/0x9d0 srp_queuecommand+0x356/0x420 [ib_srp] scsi_dispatch_cmd+0xf6/0x3f0 scsi_queue_rq+0x4a8/0x5f0 blk_mq_dispatch_rq_list+0x73/0x440 blk_mq_sched_dispatch_requests+0x109/0x1a0 __blk_mq_run_hw_queue+0x131/0x1e0 __blk_mq_delay_run_hw_queue+0x9a/0xf0 blk_mq_run_hw_queue+0xc0/0x1e0 blk_mq_start_hw_queues+0x2c/0x40 scsi_run_queue+0x18e/0x2d0 scsi_run_host_queues+0x22/0x40 scsi_error_handler+0x18d/0x5f0 kthread+0x11c/0x140 ret_from_fork+0x24/0x30 Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Laurence Oberman Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Doug Ledford Signed-off-by: Bart Van Assche --- drivers/infiniband/ulp/srp/ib_srp.c | 21 ++------------------- 1 file changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index be9ddcad8f28..b7c5a35f7daa 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2338,7 +2338,6 @@ static void srp_handle_qp_err(struct ib_cq *cq, struct ib_wc *wc, static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd) { struct srp_target_port *target = host_to_target(shost); - struct srp_rport *rport = target->rport; struct srp_rdma_ch *ch; struct srp_request *req; struct srp_iu *iu; @@ -2348,16 +2347,6 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd) u32 tag; u16 idx; int len, ret; - const bool in_scsi_eh = !in_interrupt() && current == shost->ehandler; - - /* - * The SCSI EH thread is the only context from which srp_queuecommand() - * can get invoked for blocked devices (SDEV_BLOCK / - * SDEV_CREATED_BLOCK). Avoid racing with srp_reconnect_rport() by - * locking the rport mutex if invoked from inside the SCSI EH. - */ - if (in_scsi_eh) - mutex_lock(&rport->mutex); scmnd->result = srp_chkready(target->rport); if (unlikely(scmnd->result)) @@ -2426,13 +2415,7 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd) goto err_unmap; } - ret = 0; - -unlock_rport: - if (in_scsi_eh) - mutex_unlock(&rport->mutex); - - return ret; + return 0; err_unmap: srp_unmap_data(scmnd, ch, req); @@ -2454,7 +2437,7 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd) ret = SCSI_MLQUEUE_HOST_BUSY; } - goto unlock_rport; + return ret; } /*