Message ID | 20200619033040.121412-1-david@gibson.dropbear.id.au (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | [PATCHv2] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (c3405d517d606e965030026daec198d314f20195) |
snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 26 lines checked |
snowpatch_ozlabs/needsstable | warning | Test needsstable on branch powerpc/merge |
On Fri Jun 19 20, David Gibson wrote: >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 <david@gibson.dropbear.id.au> >--- Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> > >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 >
On Fri, Jun 19, 2020 at 01:30:40PM +1000, David Gibson wrote: > 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 <david@gibson.dropbear.id.au> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> /Jarkko
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 {
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 <david@gibson.dropbear.id.au> --- 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(-)