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_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 D5827C433E1 for ; Fri, 19 Jun 2020 03:30:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2F3A2080D for ; Fri, 19 Jun 2020 03:30:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.b="RWj1rESw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730861AbgFSDau (ORCPT ); Thu, 18 Jun 2020 23:30:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730649AbgFSDas (ORCPT ); Thu, 18 Jun 2020 23:30:48 -0400 Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E27EC06174E; Thu, 18 Jun 2020 20:30:48 -0700 (PDT) Received: by ozlabs.org (Postfix, from userid 1007) id 49p4841Nvrz9sRk; Fri, 19 Jun 2020 13:30:44 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1592537444; bh=Z1znwFCrCzh+F1jGYnmAR0Tyf0EyfbusOiN3r/JH274=; h=From:To:Cc:Subject:Date:From; b=RWj1rESwwED1Om1JkEYHeCzam7cyKUIKly+0faRqHG717UTanjkbwH5ElVDAqko9S OSHLW0NYSO1vvGNnD+SG0fWsNczuNKaGJLTBQQwPrxM7Tt4gGT0w+wTMc6aLpD6lIX cRw1em/kjjIBENV9rY+9U7ezQNwhgEPwfi8vFwQE= From: David Gibson To: jarkko.sakkinen@linux.intel.com, stefanb@linux.ibm.com Cc: mpe@ellerman.id.au, peterhuewe@gmx.de, jgg@ziepe.ca, nayna@linux.ibm.com, paulus@samba.org, linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, David Gibson Subject: [PATCHv2] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes Date: Fri, 19 Jun 2020 13:30:40 +1000 Message-Id: <20200619033040.121412-1-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued, which will need the use of the internal command/response buffer. But, we're issuing this *before* we've waited to make sure that buffer is allocated. This can result in intermittent failures to probe if the hypervisor / TPM implementation doesn't respond quickly enough. I find it fails almost every time with an 8 vcpu guest under KVM with software emulated TPM. To fix it, just move the tpm2_get_cc_attrs_tlb() call after the existing code to wait for initialization, which will ensure the buffer is allocated. Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: David Gibson --- Changes from v1: * Fixed a formatting error in the commit message * Added some more detail to the commit message drivers/char/tpm/tpm_ibmvtpm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c index 09fe45246b8cc..994385bf37c0c 100644 --- a/drivers/char/tpm/tpm_ibmvtpm.c +++ b/drivers/char/tpm/tpm_ibmvtpm.c @@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev, if (rc) goto init_irq_cleanup; - if (!strcmp(id->compat, "IBM,vtpm20")) { - chip->flags |= TPM_CHIP_FLAG_TPM2; - rc = tpm2_get_cc_attrs_tbl(chip); - if (rc) - goto init_irq_cleanup; - } - if (!wait_event_timeout(ibmvtpm->crq_queue.wq, ibmvtpm->rtce_buf != NULL, HZ)) { @@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev, goto init_irq_cleanup; } + if (!strcmp(id->compat, "IBM,vtpm20")) { + chip->flags |= TPM_CHIP_FLAG_TPM2; + rc = tpm2_get_cc_attrs_tbl(chip); + if (rc) + goto init_irq_cleanup; + } + return tpm_chip_register(chip); init_irq_cleanup: do { -- 2.26.2 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.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 E76AEC433DF for ; Fri, 19 Jun 2020 03:32:15 +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 211D92080D for ; Fri, 19 Jun 2020 03:32:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.b="RWj1rESw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 211D92080D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au 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 49p49n1rP3zDrMJ for ; Fri, 19 Jun 2020 13:32:13 +1000 (AEST) Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 49p4851j2vzDrM2 for ; Fri, 19 Jun 2020 13:30:45 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=201602 header.b=RWj1rESw; dkim-atps=neutral Received: by ozlabs.org (Postfix, from userid 1007) id 49p4841Nvrz9sRk; Fri, 19 Jun 2020 13:30:44 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1592537444; bh=Z1znwFCrCzh+F1jGYnmAR0Tyf0EyfbusOiN3r/JH274=; h=From:To:Cc:Subject:Date:From; b=RWj1rESwwED1Om1JkEYHeCzam7cyKUIKly+0faRqHG717UTanjkbwH5ElVDAqko9S OSHLW0NYSO1vvGNnD+SG0fWsNczuNKaGJLTBQQwPrxM7Tt4gGT0w+wTMc6aLpD6lIX cRw1em/kjjIBENV9rY+9U7ezQNwhgEPwfi8vFwQE= From: David Gibson To: jarkko.sakkinen@linux.intel.com, stefanb@linux.ibm.com Subject: [PATCHv2] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes Date: Fri, 19 Jun 2020 13:30:40 +1000 Message-Id: <20200619033040.121412-1-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 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: nayna@linux.ibm.com, linux-kernel@vger.kernel.org, jgg@ziepe.ca, paulus@samba.org, peterhuewe@gmx.de, linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org, David Gibson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued, which will need the use of the internal command/response buffer. But, we're issuing this *before* we've waited to make sure that buffer is allocated. This can result in intermittent failures to probe if the hypervisor / TPM implementation doesn't respond quickly enough. I find it fails almost every time with an 8 vcpu guest under KVM with software emulated TPM. To fix it, just move the tpm2_get_cc_attrs_tlb() call after the existing code to wait for initialization, which will ensure the buffer is allocated. Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: David Gibson --- Changes from v1: * Fixed a formatting error in the commit message * Added some more detail to the commit message drivers/char/tpm/tpm_ibmvtpm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c index 09fe45246b8cc..994385bf37c0c 100644 --- a/drivers/char/tpm/tpm_ibmvtpm.c +++ b/drivers/char/tpm/tpm_ibmvtpm.c @@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev, if (rc) goto init_irq_cleanup; - if (!strcmp(id->compat, "IBM,vtpm20")) { - chip->flags |= TPM_CHIP_FLAG_TPM2; - rc = tpm2_get_cc_attrs_tbl(chip); - if (rc) - goto init_irq_cleanup; - } - if (!wait_event_timeout(ibmvtpm->crq_queue.wq, ibmvtpm->rtce_buf != NULL, HZ)) { @@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev, goto init_irq_cleanup; } + if (!strcmp(id->compat, "IBM,vtpm20")) { + chip->flags |= TPM_CHIP_FLAG_TPM2; + rc = tpm2_get_cc_attrs_tbl(chip); + if (rc) + goto init_irq_cleanup; + } + return tpm_chip_register(chip); init_irq_cleanup: do { -- 2.26.2