From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A48CC43387 for ; Thu, 17 Jan 2019 00:27:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 37B1A20675 for ; Thu, 17 Jan 2019 00:27:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=mailprotect.be header.i=@mailprotect.be header.b="tFzGQUui" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728706AbfAQA1g (ORCPT ); Wed, 16 Jan 2019 19:27:36 -0500 Received: from out002.mailprotect.be ([83.217.72.86]:59341 "EHLO out002.mailprotect.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728699AbfAQA1f (ORCPT ); Wed, 16 Jan 2019 19:27:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailprotect.be; s=mail; h=Content-Transfer-Encoding:MIME-Version:References :In-Reply-To:Message-Id:Date:Subject:Cc:To:From:reply-to:sender:bcc: content-type; bh=Dn1d8vIjVD9ldUBHmwLPVMW3FX2KlHGO1mhxo3ZRvNk=; b=tFzGQUuioqZP p2LKDZIt/gXx4OzfZez/v8a+ceB+lXbWtkq94js9Dqn0p5UMdwIFTdL8n0vFlt7Dr7z/CrMmT31sL UcLI4pJTvl0nBlqyVT1W0Hu0fCr9sTp5k2BEFVxJqgIJSM2sxWPHDauFHu0mrN+QbEYEC1EsEFh+C /jD4R5/t290klZG2C1YY/I8kTJWN8gESQUe8yEeQWSmHZPZoqsyAmiTTzpqZTYZsdP+o8GMOX/MXT PcD56NSiXyLcUIcj/VT+0y/1p1nnL9DMLWT9VXGsTDzkkAcvCF1Yksi3aMcE+G3uvOWhzo+25yhPt GsvkQ/jv5sSSY5Xv1jVK7A==; Received: from smtp-auth.mailprotect.be ([178.208.39.159]) by com-mpt-out002.mailprotect.be with esmtp (Exim 4.89) (envelope-from ) id 1gjvWt-0007EV-2B; Thu, 17 Jan 2019 01:27:31 +0100 Received: from desktop-bart.svl.corp.google.com (unknown [104.133.8.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-auth.mailprotect.be (Postfix) with ESMTPSA id 1853CC07AC; Thu, 17 Jan 2019 01:27:27 +0100 (CET) From: Bart Van Assche To: Jason Gunthorpe Cc: Doug Ledford , linux-rdma@vger.kernel.org, Bart Van Assche , Sergey Gorenko , Max Gurtovoy , Laurence Oberman , stable@vger.kernel.org Subject: [PATCH 1/2] RDMA/srp: Avoid calling mutex_lock() from inside scsi_queue_rq() Date: Wed, 16 Jan 2019 16:27:16 -0800 Message-Id: <20190117002717.84686-2-bvanassche@acm.org> X-Mailer: git-send-email 2.20.1.97.g81188d93c3-goog In-Reply-To: <20190117002717.84686-1-bvanassche@acm.org> References: <20190117002717.84686-1-bvanassche@acm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: 178.208.39.159 X-SpamExperts-Domain: mailprotect.be X-SpamExperts-Username: 178.208.39.128/27 Authentication-Results: mailprotect.be; auth=pass smtp.auth=178.208.39.128/27@mailprotect.be X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.01) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ueUEAFQkpEAHcb2zZYwO1x602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO1tLifGj39bI0bcPyaJsYTbLl/LY5YF9Vo2OhJGJjKCGCCZpQ81ZPiyihk8FOHdtvo4l V1QHumGYL6MoCWQBeDaU32qUPOJX7vhbzYcc5l71m4VKGlZauPS2ZI2/MGgfC8Av92G8VFvri8dZ 651y1LnBHvoYB1tNyzlE795H++xpIGTTJ1+gdXdk1Q+yT5nnagoNQ5DNiL8QB+UJGT4JjCrpphyP UPt9zJpS4kKwchXeopkI3zP1E6WYjFDj3Po4VtbjuU58k6ddZEUemp+2z72yjI5s8Y8mEzss0P1Z PFJSTWUth/bIg1D/4cblfXFvIrwhcbIgt0qoJA65s+aV0TNSu4Q1sJN0pTPPGPEcb1FCr3OnWExh FqqXKjnbUDBzcE+0HNyHhfqG0xcyQsZuCSP9hsa4s5F3MydIviotZvNHMvzpHD6s+1ao4iJ4PfBj 2N8Vdv96d+08iDufvobw6VUavl4snG+PRn+T8pp7vQV3rpLvOUh2w8gsgLX0uFSNx2AewJvG2VR5 mIGCzCE3N/asZm+FB8yckvFZiHWxnQEMkunODYtbvP72vAmOyjpz9UIDBHPtf27+c3J1HwicUV+G pS+C6BPAIEs8PiiVo3Eb3c7KClSBOi3EV0NWbVJ1KXxqWKxJiDvSXvZvXfo2UEYR9G8HIfDm0MPW TzQicTC9GplHcpVCCoX989hgB8R+yC9G9b3yazdC1eGXzxVaKpgg1grWUX/HgdX4VFm5j58jirfd PfGcwP92aCa0EBrwzJTIqsriZLvaiGZnz91zoAMokdMyijyrNPLF2pjbdb3MosfYiA+A0wZZjhdL 0PpC7BEVniihuDwEGDcmr6e3OPQT0DVFoMDBp5PRUiQzcTDLKXYp8mSktA5RGpHjopTdf5YiqaSo bdv/FvB9xwlPxWQhAvBZFjHncP/RkK4WfbUgctgzcDoFd+96Xw4QUNtTnccFhhwn2/Dj1pgXRdkG FXml68sVQdV8jHytZ27+31Y2za3muS2OYzrgPLHf0Rbu9udKEy7bP5gIt23U7fpAnNPRUBWWBSDR x5OeloKLHRs0g0z5EfZrz6E5xburfSl74HBEn95eECKi3gxjzXac2CIo7bSWHMwv14kxH53zEku4 6CxjyQf09M5rialBcVt4x9u3hHG5f/LZAZC2bUhjWf0= X-Report-Abuse-To: spam@com-mpt-mgt001.mailprotect.be Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org srp_queuecommand() can be called from the following contexts: * From inside scsi_queue_rq(). This function can be called by several kernel threads, including the SCSI error handler thread. * From inside scsi_send_eh_cmnd(). This function is only called from the SCSI error handler thread. In scsi-mq mode it is not allowed to sleep inside srp_queuecommand() since the flag BLK_MQ_F_BLOCKING has not been set. Since setting the request queue flag BLK_MQ_F_BLOCKING would slow down the hot path, make srp_queuecommand() skip the mutex_lock() and mutex_unlock() calls when called from inside scsi_queue_rq() from the SCSI EH thread. This patch avoids that the following appears in the kernel log: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 in_atomic(): 1, irqs_disabled(): 0, pid: 30974, name: scsi_eh_4 INFO: lockdep is turned off. Preemption disabled at: [] __blk_mq_delay_run_hw_queue+0x185/0x290 CPU: 3 PID: 30974 Comm: scsi_eh_4 Not tainted 4.20.0-rc6-dbg+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0x86/0xca ___might_sleep.cold.80+0x128/0x139 __might_sleep+0x71/0xe0 __mutex_lock+0xc8/0xbe0 mutex_lock_nested+0x1b/0x20 srp_queuecommand+0x7f2/0x19a0 [ib_srp] scsi_dispatch_cmd+0x15d/0x510 scsi_queue_rq+0x123/0xa90 blk_mq_dispatch_rq_list+0x678/0xc20 blk_mq_sched_dispatch_requests+0x25c/0x310 __blk_mq_run_hw_queue+0xd6/0x180 __blk_mq_delay_run_hw_queue+0x262/0x290 blk_mq_run_hw_queue+0x11f/0x1b0 blk_mq_run_hw_queues+0x87/0xb0 scsi_run_queue+0x402/0x6f0 scsi_run_host_queues+0x30/0x50 scsi_error_handler+0x2d3/0xa80 kthread+0x1cf/0x1f0 ret_from_fork+0x24/0x30 Cc: Sergey Gorenko Cc: Max Gurtovoy Cc: Laurence Oberman Cc: Fixes: a95cadb9dafe ("IB/srp: Add periodic reconnect functionality") # v3.13 Signed-off-by: Bart Van Assche --- drivers/infiniband/ulp/srp/ib_srp.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 31d91538bbf4..23e5c9afb8fb 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2352,13 +2352,19 @@ 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; + const bool in_scsi_eh = !in_interrupt() && current == shost->ehandler + && rcu_preempt_depth() == 0; /* - * The SCSI EH thread is the only context from which srp_queuecommand() - * can get invoked for blocked devices (SDEV_BLOCK / + * The scsi_send_eh_cmnd() function is the only function that can call + * .queuecommand() 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. + * locking the rport mutex if invoked from inside that function. + * Recognize this context by checking whether called from the SCSI EH + * thread and whether no RCU read lock is held. If + * blk_mq_run_hw_queues() is called from the context of the SCSI EH + * thread then an RCU read lock is held around scsi_queue_rq() calls + * becase the SRP driver does not set BLK_MQ_F_BLOCKING. */ if (in_scsi_eh) mutex_lock(&rport->mutex); -- 2.20.1.97.g81188d93c3-goog