All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jerry Snitselaar <jsnitsel@redhat.com>
Cc: linux-integrity@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Peter Huewe <peterhuewe@gmx.de>
Subject: Re: [PATCH 1/4] tpm_tis: Clean up locality release
Date: Wed, 30 Sep 2020 16:03:25 -0700	[thread overview]
Message-ID: <8ed5a80a9b2cfa37f0b8348906d292a7b1a1c02e.camel@HansenPartnership.com> (raw)
In-Reply-To: <87eemjgdy3.fsf@jsnitsel.users.ipa.redhat.com>

On Wed, 2020-09-30 at 14:19 -0700, Jerry Snitselaar wrote:
> James Bottomley @ 2020-09-29 15:32 MST:
> 
> > The current release locality code seems to be based on the
> > misunderstanding that the TPM interrupts when a locality is
> > released: it doesn't, only when the locality is acquired.
> > 
> > Furthermore, there seems to be no point in waiting for the locality
> > to be released.  All it does is penalize the last TPM
> > user.  However, if there's no next TPM user, this is a pointless
> > wait and if there is
> > a
> > next TPM user, they'll pay the penalty waiting for the new locality
> > (or possibly not if it's the same as the old locality).
> > 
> > Fix the code by making release_locality as simple write to release
> > with no waiting for completion.
[...]
> My recollection is that this was added because there were some chips
> that took so long to release locality that a subsequent
> request_locality call was seeing the locality as already active,
> moving on, and then the locality was getting released out from under
> the user.

Well, I could simply dump the interrupt code, which can never work and
we could always poll.

However, there also appears to be a bug in our locality requesting
code.  We write the request and wait for the grant, but a grant should
be signalled by not only the ACCESS_ACTIVE_LOCALITY being 1 but also
the ACCESS_REQUEST_USE going to 0.  As you say, if we're slow to
relinquish, ACCESS_ACTIVE_LOCALITY could already be 1 and we'd think we
were granted, but ACCESS_REQUEST_USE should stay 1 until the TPM
actually grants the next request.

If I code up a fix is there any chance you still have access to a
problem TPM?  Mine all seem to grant and release localities fairly
instantaneously.

James




  reply	other threads:[~2020-09-30 23:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 22:32 [PATCH 0/4] tpm_tis: fix interrupts (again) James Bottomley
2020-09-29 22:32 ` [PATCH 1/4] tpm_tis: Clean up locality release James Bottomley
2020-09-30  2:26   ` Jarkko Sakkinen
2020-09-30  2:26     ` Jarkko Sakkinen
2020-09-30 21:19   ` Jerry Snitselaar
2020-09-30 23:03     ` James Bottomley [this message]
2020-10-01  0:01       ` Jerry Snitselaar
2020-10-01 15:58         ` James Bottomley
2021-01-02  1:17           ` Laurent Bigonville
2020-10-01  2:01       ` Jarkko Sakkinen
2020-10-01  4:49         ` James Bottomley
2020-10-01 17:48           ` James Bottomley
2020-09-29 22:32 ` [PATCH 2/4] tpm_tis: Fix interrupts for TIS TPMs without legacy cycles James Bottomley
2020-09-30  2:39   ` Jarkko Sakkinen
2020-09-29 22:32 ` [PATCH 3/4] tpm_tis: fix IRQ probing James Bottomley
2020-09-30  2:40   ` Jarkko Sakkinen
2020-09-29 22:32 ` [PATCH 4/4] Revert "tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"" James Bottomley
2020-09-30  2:40   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8ed5a80a9b2cfa37f0b8348906d292a7b1a1c02e.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=jsnitsel@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.