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=-9.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 DA1DEC433E0 for ; Thu, 18 Jun 2020 03:03:20 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 886B4208C7 for ; Thu, 18 Jun 2020 03:03:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0T+f9RVV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 886B4208C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 49nRZt3C6pzDr4g for ; Thu, 18 Jun 2020 13:03:18 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=sashal@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=0T+f9RVV; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 49nPFt1J1PzDqtN for ; Thu, 18 Jun 2020 11:18:26 +1000 (AEST) Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3433121D80; Thu, 18 Jun 2020 01:18:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592443104; bh=IYJNKOK5cBTrSDuxAQOv5bJd8WQAogwI6p6Osfy88qk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0T+f9RVVmOfgFhXirxqXB0bjab4QwfK8kgO1AgHQkmy32g6DIFDyc1RXzsKsdi9bz xX4UzbhMddKb9df2DBbD/pjPo8N0jF8sQB3PNESSryze2EID7JY+ult60LNfL+zQO9 4QVa4L6RHSUurnOYPZ+wuOaq89767Gk31et5faUE= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH AUTOSEL 5.4 082/266] scsi: ibmvscsi: Don't send host info in adapter info MAD after LPM Date: Wed, 17 Jun 2020 21:13:27 -0400 Message-Id: <20200618011631.604574-82-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200618011631.604574-1-sashal@kernel.org> References: <20200618011631.604574-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , Tyrel Datwyler , linuxppc-dev@lists.ozlabs.org, linux-scsi@vger.kernel.org, "Martin K . Petersen" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" From: Tyrel Datwyler [ Upstream commit 4919b33b63c8b69d8dcf2b867431d0e3b6dc6d28 ] The adapter info MAD is used to send the client info and receive the host info as a response. A persistent buffer is used and as such the client info is overwritten after the response. During the course of a normal adapter reset the client info is refreshed in the buffer in preparation for sending the adapter info MAD. However, in the special case of LPM where we reenable the CRQ instead of a full CRQ teardown and reset we fail to refresh the client info in the adapter info buffer. As a result, after Live Partition Migration (LPM) we erroneously report the host's info as our own. [mkp: typos] Link: https://lore.kernel.org/r/20200603203632.18426-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/ibmvscsi/ibmvscsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index 59f0f1030c54..c5711c659b51 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -415,6 +415,8 @@ static int ibmvscsi_reenable_crq_queue(struct crq_queue *queue, int rc = 0; struct vio_dev *vdev = to_vio_dev(hostdata->dev); + set_adapter_info(hostdata); + /* Re-enable the CRQ */ do { if (rc) -- 2.25.1