On Mon, Oct 05, 2020 at 12:05:07PM -0700, James Bottomley wrote:
> On Mon, 2020-10-05 at 20:02 +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 01, 2020 at 11:09:22AM -0700, James Bottomley wrote:
> > > 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.
> > >
> > > Fixes: 33bafe90824b ("tpm_tis: verify locality released before
> > > returning from release_locality")
> > > Signed-off-by: James Bottomley <
> > > James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> >
> > So, if I got it right this is dependent on 1/5 to address Jerry's
> > issue? I.e. if this has a fixes tag and previous does not, it will
> > not fully fix the situation when backporting?
>
> Yes, exactly. Technically 1/5 isn't really fixing anything at all,
> it's changing from the current fix where we wait for the locality to be
> released at the back end of a TIS TPM operation to a new fix where we
> correctly check the conditions in the locality acquisition. After the
> new fix is done, we can eliminate all the wait code in locality
> release.
>
> James
OK, ignore my changelog etc. cosmectic comments unless there is need
for another revision. I will add the necessary tags.
I'm holding with reviewed-by up until Jerry can get ack for these
changes. If he ack's, the it's all good as far as I'm concerned.
/Jarkko
