From patchwork Mon Sep 21 16:27:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 309291 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=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, 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 1BFA4C43466 for ; Mon, 21 Sep 2020 17:06:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E337C2084C for ; Mon, 21 Sep 2020 17:06:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600707988; bh=kAMW49P1gnd6Q7vgEB8RTzXo+02ZKiNLkrobbCM3QN8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=PSKteAWhlfMxl1V+t91dalBKkex7muKHEQFpWTF4fqQxyyAlchq686hbr2vfWVCed LkeCLgLvh04HiNGHdaL0qPUXNr+tPMAZ00GuSMgBB/S2+TeWn+JCIW82q/eA1RvCSt 2cAYlLyHw4cZIxykdkk/nsFsFNRJebPDwZDsnVQg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730257AbgIURG1 (ORCPT ); Mon, 21 Sep 2020 13:06:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:58392 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728518AbgIUQcl (ORCPT ); Mon, 21 Sep 2020 12:32:41 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1D19D239EB; Mon, 21 Sep 2020 16:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600705960; bh=kAMW49P1gnd6Q7vgEB8RTzXo+02ZKiNLkrobbCM3QN8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P5tlKJDeR/4bVF5cT7IkBnegW7OGrMkbtW1cVKVrMl2YHaJvBtP24mkEA7qJvWUnC JQ01C7ygVWwAIi64q6k/fzYr8Ffwm1eZEp/HC8hEOgDU2DeGkwPngVrE36B5tKYZL3 hG0/PwTMJOFlcCXle0aVNatxGrclNL8Ce2DXl1e0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dick Kennedy , James Smart , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 4.4 31/46] scsi: lpfc: Fix FLOGI/PLOGI receive race condition in pt2pt discovery Date: Mon, 21 Sep 2020 18:27:47 +0200 Message-Id: <20200921162034.739599477@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200921162033.346434578@linuxfoundation.org> References: <20200921162033.346434578@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: James Smart [ Upstream commit 7b08e89f98cee9907895fabb64cf437bc505ce9a ] The driver is unable to successfully login with remote device. During pt2pt login, the driver completes its FLOGI request with the remote device having WWN precedence. The remote device issues its own (delayed) FLOGI after accepting the driver's and, upon transmitting the FLOGI, immediately recognizes it has already processed the driver's FLOGI thus it transitions to sending a PLOGI before waiting for an ACC to its FLOGI. In the driver, the FLOGI is received and an ACC sent, followed by the PLOGI being received and an ACC sent. The issue is that the PLOGI reception occurs before the response from the adapter from the FLOGI ACC is received. Processing of the PLOGI sets state flags to perform the REG_RPI mailbox command and proceed with the rest of discovery on the port. The same completion routine used by both FLOGI and PLOGI is generic in nature. One of the things it does is clear flags, and those flags happen to drive the rest of discovery. So what happened was the PLOGI processing set the flags, the FLOGI ACC completion cleared them, thus when the PLOGI ACC completes it doesn't see the flags and stops. Fix by modifying the generic completion routine to not clear the rest of discovery flag (NLP_ACC_REGLOGIN) unless the completion is also associated with performing a mailbox command as part of its handling. For things such as FLOGI ACC, there isn't a subsequent action to perform with the adapter, thus there is no mailbox cmd ptr. PLOGI ACC though will perform REG_RPI upon completion, thus there is a mailbox cmd ptr. Link: https://lore.kernel.org/r/20200828175332.130300-3-james.smart@broadcom.com Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/lpfc/lpfc_els.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c index 315dd25a0c44e..5be938b47f48b 100644 --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -3841,7 +3841,9 @@ lpfc_cmpl_els_rsp(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb, out: if (ndlp && NLP_CHK_NODE_ACT(ndlp) && shost) { spin_lock_irq(shost->host_lock); - ndlp->nlp_flag &= ~(NLP_ACC_REGLOGIN | NLP_RM_DFLT_RPI); + if (mbox) + ndlp->nlp_flag &= ~NLP_ACC_REGLOGIN; + ndlp->nlp_flag &= ~NLP_RM_DFLT_RPI; spin_unlock_irq(shost->host_lock); /* If the node is not being used by another discovery thread,