From patchwork Thu Mar 17 15:34:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: patricia.domingues@canonical.com X-Patchwork-Id: 1606627 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=oTTyBtci; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KKB7T1kNLz9s2R for ; Fri, 18 Mar 2022 02:36:05 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1nUsAP-00079g-MY; Thu, 17 Mar 2022 15:35:57 +0000 Received: from smtp-relay-canonical-0.internal ([10.131.114.83] helo=smtp-relay-canonical-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1nUsAM-00077S-9K for kernel-team@lists.ubuntu.com; Thu, 17 Mar 2022 15:35:54 +0000 Received: from localhost.localdomain (1.general.patriciasd.us.vpn [10.172.64.192]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id 4FF243F646 for ; Thu, 17 Mar 2022 15:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1647531354; bh=OxJR6gWWLy8/0QJ+bdiy4Q0TjI8ODeMDaMc4P/VFSlc=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References; b=oTTyBtciQzl7sCU9zwD0NnIdmKKGYrkFiM5hw/M3Cn4ak1+bcNknTI+om0KEJFM9Z GoRoPPUwsNA/HFLwsfg48cdnJ91mESMrJg2UURLrP8xlTF8pk+GU37XWQLR1ewe//3 aJCgZMUgWLf7gcM93/fyra48vQ7pR0tduprX9IKFAr+ekWd7nFanCCpnaVU1JQiqlR 6IxXQc+OI2WgZgiqgf4IA+eEZLLFRUOi9kdHUq4CxHnT1qwnj9adpJtX6ND03xkV3/ UaiyKQC2f1me9Yd8HACzIwbo+9usfSJTc2hKz0DtSPFxzu01xcifeEuLCLWohHad0T xJeh4IpByU9yw== From: patricia.domingues@canonical.com To: kernel-team@lists.ubuntu.com Subject: [J][PATCH 1/6] s390/pci: tolerate inconsistent handle in recover Date: Thu, 17 Mar 2022 12:34:58 -0300 Message-Id: <20220317153503.12817-2-patricia.domingues@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220317153503.12817-1-patricia.domingues@canonical.com> References: <20220317153503.12817-1-patricia.domingues@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Niklas Schnelle BugLink: https://bugs.launchpad.net/bugs/1959532 Since commit 8256adda1f44 ("s390/pci: handle FH state mismatch only on disable") zpci_disable_device() returns -EINVAL when the platform detects an attempt to disable a PCI function that it sees as already disabled. In most situations we want to abort whenever this happens and abort is possible since it either means that the device vanished but we haven't gotten an availability event yet, or the FH got out of sync which should not happen. Unfortunately there is an inconsistency between the LPAR and z/VM hypervisors on whether error events for PCI functions contain an an enabled or a general handle. So under z/VM it can happen that our most up to date function handle is enabled but trying to disable the function results in the aforementioned error. Since recover is designed to be used to recover functions from the error state let's make it robust to this inconsistency by explicitly treating it as a successful disable. Acked-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik (cherry picked from commit 1c8174fdc798489159a79466fca782daa231219a) Signed-off-by: Patricia Domingues --- arch/s390/pci/pci_sysfs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/s390/pci/pci_sysfs.c b/arch/s390/pci/pci_sysfs.c index 335c281811c7..cae280e5c047 100644 --- a/arch/s390/pci/pci_sysfs.c +++ b/arch/s390/pci/pci_sysfs.c @@ -90,6 +90,14 @@ static ssize_t recover_store(struct device *dev, struct device_attribute *attr, if (zdev_enabled(zdev)) { ret = zpci_disable_device(zdev); + /* + * Due to a z/VM vs LPAR inconsistency in the error + * state the FH may indicate an enabled device but + * disable says the device is already disabled don't + * treat it as an error here. + */ + if (ret == -EINVAL) + ret = 0; if (ret) goto out; }