From patchwork Wed Jun 5 20:14:33 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: 10977775 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 A800014B6 for ; Wed, 5 Jun 2019 20:14:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9C62628449 for ; Wed, 5 Jun 2019 20:14:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8E13E28714; Wed, 5 Jun 2019 20:14:46 +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 0585C28714 for ; Wed, 5 Jun 2019 20:14:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726606AbfFEUOp (ORCPT ); Wed, 5 Jun 2019 16:14:45 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:45814 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726502AbfFEUOp (ORCPT ); Wed, 5 Jun 2019 16:14:45 -0400 Received: by mail-pl1-f193.google.com with SMTP id x7so9112934plr.12 for ; Wed, 05 Jun 2019 13:14:44 -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=pmf/KgJRX3ZfNGi1Ar+6cR+r6SXrnjSikFKADv1dHH4=; b=tYK2SRWatGR8wiYga1AjBzTi9cvgidVJAlwFTrlVkgMKfn/oJ3qzHOydqvH9MMGpSp pf0CU2DyiL0WpSHI7blrAVhPb+5GxP5CMcn+guw7n7LEoeGIgvzHdvyDAnJfQ1iNp1fG KVwA/sQ4+ZZQAxk85IxYHdVFHKNFaYWsVMBG8AlouxHKb7RjnoATtVpNyb1IDKI7K6pV OwinhTBFaDPpVS+tgN08lHJq/1O8PnwxsOBNHsupLzwxFz36K6WGhm0dOBbOtpXYVHja 5KnFRWw65VZHzY7xxOYSVQ5L03G6KYKD1Pgi8kOdPkRY2zru/cer3lH98+QQLVW5oFAd rXOw== X-Gm-Message-State: APjAAAUoa9tjk8oPO8UMV1xVqMUmgrBDL3PDYw/Qr0jUGfM/rXSZBZUf bxeAkcp9blg5ad+H+KpAqt0= X-Google-Smtp-Source: APXvYqzk/NLhG+xgcSp7YS3liRGorJFLPwZDnzQFMyH6CR6xXiJ8FY0UWyYabzWjOj8UtMGSkrowrA== X-Received: by 2002:a17:902:8a83:: with SMTP id p3mr46926275plo.88.1559765684380; Wed, 05 Jun 2019 13:14:44 -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 c129sm27135926pfa.106.2019.06.05.13.14.43 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 05 Jun 2019 13:14:43 -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 Subject: [PATCH 1/3] scsi: Do not allow user space to change the SCSI device state into SDEV_BLOCK Date: Wed, 5 Jun 2019 13:14:33 -0700 Message-Id: <20190605201435.233701-2-bvanassche@acm.org> X-Mailer: git-send-email 2.20.GIT In-Reply-To: <20190605201435.233701-1-bvanassche@acm.org> References: <20190605201435.233701-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. 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. Notes: - While SDEV_BLOCK blocks all SCSI commands, in the SDEV_QUIESCE state only those block layer requests are blocked for which RQF_PREEMPT has not been set. RQF_PREEMPT is not set for I/O requests submitted by e.g. a filesystem but is set for all requests pass-through requests. See also __scsi_execute(). - By doing a web search for ("blocked" OR "quiesce") AND "/sys/class/scsi_device" AND "device/state" I found 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 Signed-off-by: Bart Van Assche Reviewed-by: Christoph Hellwig --- drivers/scsi/scsi_sysfs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index ff0aea7ac87f..a49ee113b3c4 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -769,6 +769,13 @@ store_state_field(struct device *dev, struct device_attribute *attr, } if (!state) return -EINVAL; + /* + * The state SDEV_BLOCK should not be set from userspace. Translate + * SDEV_BLOCK into SDEV_QUIESCE in case the SDEV_BLOCK state transition + * is requested from user space. + */ + if (state == SDEV_BLOCK) + state = SDEV_QUIESCE; mutex_lock(&sdev->state_mutex); ret = scsi_device_set_state(sdev, state); From patchwork Wed Jun 5 20:14:34 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: 10977777 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 7796014B6 for ; Wed, 5 Jun 2019 20:14:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6B04828972 for ; Wed, 5 Jun 2019 20:14:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5EE012897A; Wed, 5 Jun 2019 20:14:47 +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 E87A328957 for ; Wed, 5 Jun 2019 20:14:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726626AbfFEUOq (ORCPT ); Wed, 5 Jun 2019 16:14:46 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:32814 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726502AbfFEUOq (ORCPT ); Wed, 5 Jun 2019 16:14:46 -0400 Received: by mail-pl1-f195.google.com with SMTP id g21so10114011plq.0 for ; Wed, 05 Jun 2019 13:14:46 -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=W2xcP3+srpIJOPIE+RfP1Whw18wv/tP9VDiA3Wch55U=; b=LF+tBIokMlwXiHyI1ldFeBMrpiU+49lhcX/l3EIBMPq4lIsdlP7mk/Qdv87Evimenn Uksco26+Vf+WkXZ6bv3QGF52GvENhO+gJ19d0OeC1iHA3yZmqfR50q0rBXCiQ1uqjOV2 TkljMH/xZ9lHo/pyvQ7MhRgDS6w1DJEn1gHih1UdRcEqfxgkYF4SBek8eWzpH0DV0gKp yEZsNpaolymQ+S7T2HKDWPWu8YKmgsFcOm9fhPOSK77v2+VzpTHUG7bkggmh1F+CLGm2 4LUGptqo9H3CLrgu+zoVS+2h96tZfna8/Hr9EUKQA5CVygbQDg8lm8QmlaxTpqIZNy2G joMA== X-Gm-Message-State: APjAAAWJIq6IvROvpJhWyPLXgp3Yq9lf2i4/mydjbAuHbHUwrgzaxSJp Ji7lCaOJ9yIq+YBqLsJ1w/U= X-Google-Smtp-Source: APXvYqzZP4lI5mOrZykX6YlVTbKArsDdxBszYZVfzKva6X6ZH1JASgsSJDH3e0H9cbZQqfHna5Buuw== X-Received: by 2002:a17:902:3341:: with SMTP id a59mr17644516plc.186.1559765685645; Wed, 05 Jun 2019 13:14:45 -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 c129sm27135926pfa.106.2019.06.05.13.14.44 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 05 Jun 2019 13:14:44 -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 2/3] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device Date: Wed, 5 Jun 2019 13:14:34 -0700 Message-Id: <20190605201435.233701-3-bvanassche@acm.org> X-Mailer: git-send-email 2.20.GIT In-Reply-To: <20190605201435.233701-1-bvanassche@acm.org> References: <20190605201435.233701-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 quiesced 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. Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: Johannes Thumshirn Signed-off-by: Bart Van Assche Reviewed-by: Christoph Hellwig --- drivers/scsi/scsi_error.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index f490994374f6..9f16304150b1 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -1055,7 +1055,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; @@ -1066,7 +1066,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); From patchwork Wed Jun 5 20:14:35 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: 10977779 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 E8FBE13AD for ; Wed, 5 Jun 2019 20:14:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DB79D282EC for ; Wed, 5 Jun 2019 20:14:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CFC8928957; Wed, 5 Jun 2019 20:14:48 +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 540A0282EC for ; Wed, 5 Jun 2019 20:14:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726633AbfFEUOs (ORCPT ); Wed, 5 Jun 2019 16:14:48 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:39685 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726502AbfFEUOr (ORCPT ); Wed, 5 Jun 2019 16:14:47 -0400 Received: by mail-pf1-f195.google.com with SMTP id j2so15488572pfe.6 for ; Wed, 05 Jun 2019 13:14:47 -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=wsFKYvKfAQ1BADbwFnQB+QnvzqWHxt5GCYWr97i9qkI=; b=U2uaUrLoyGoQ528wWVXsii3ocDUt/pui+LoS+znql4hHdFnHSfK1IRnP6O7YhFAywa ZpbJQzlhJMsFkHnvqQlq6RNoQe+CEky+sGPiahcbzlGdpkD25NWNsAC8sTlovblUUaV9 noTIZRHzQ0A0xf0F0o+kWcRYlaAh87kkHo/nONkHYULQDsgaXebRWbNNjhNQJ4JhluFy l5axiVJohb9mlOBB5eLQ1+DZeqZ3NTW3cPa+j8PZwnBotXKxlyHg+5R8aDDOPpFx/YLO ww0AaUKIp8HSSZSo97AnyrrpmHl/XmZaH+76xlI7CLIx4V+rN0PgsFkyejK8l6JTuprK +OSg== X-Gm-Message-State: APjAAAXE6TG+93z0aclh6kexOuAzD+M7wZD0HCFxmjGnqxE+LfugU6xX kHxCt1HWEKbI8G/g59L4qAQ= X-Google-Smtp-Source: APXvYqyaP+LEhFrS0V0DGSfkt3We01XFOMVhglCSgesHRZ5wOvzHahzGlQwBGWniF3KNE60YU3Tysg== X-Received: by 2002:a62:ed09:: with SMTP id u9mr48806141pfh.23.1559765686826; Wed, 05 Jun 2019 13:14:46 -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 c129sm27135926pfa.106.2019.06.05.13.14.45 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 05 Jun 2019 13:14:46 -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 , Jason Gunthorpe , Leon Romanovsky , Doug Ledford , Laurence Oberman Subject: [PATCH 3/3] RDMA/srp: Fix a sleep-in-invalid-context bug Date: Wed, 5 Jun 2019 13:14:35 -0700 Message-Id: <20190605201435.233701-4-bvanassche@acm.org> X-Mailer: git-send-email 2.20.GIT In-Reply-To: <20190605201435.233701-1-bvanassche@acm.org> References: <20190605201435.233701-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 Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Doug Ledford Cc: Laurence Oberman Signed-off-by: Bart Van Assche Reviewed-by: Laurence Oberman Reviewed-by: Christoph Hellwig --- 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; } /*