lkml.org 
[lkml]   [2017]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC 1/4] tpm: migrate struct tpm_buf to struct tpm_chip
    On Mon, Jan 02, 2017 at 02:01:01PM -0700, Jason Gunthorpe wrote:
    > On Mon, Jan 02, 2017 at 03:22:07PM +0200, Jarkko Sakkinen wrote:
    > > Since there is only one thread using TPM chip at a time to transmit data
    > > we can migrate struct tpm_buf to struct tpm_chip. This makes the use of
    > > it more fail safe as the buffer is allocated from heap when the device
    > > is created and not for every transaction.
    >
    > Eh? What? I don't think that is the case..
    >
    > We don't serialize until we hit tramsit_cmd at which point the buffer
    > is already being used and cannot be shared between threads.

    There is a regression in the patch. All functions that use 'tr_buf'
    should take tpm_mutex first and use TPM_TRANSMIT_UNLOCKED. There's
    also a similar regression in TPM space patch that I have to correct.

    > Why would the resource manager need a single global tpm buffer? That
    > seems like a big regression from where we have been going. I don't
    > think this is a good idea to go down this road.

    What? 'tr_buf' is not specifically for resource manager. This commit
    makes creating TPM commands more fail-safe because there is no need
    to allocate page for every transmit.

    For RM decorations this is really important because I rather would have
    them fail as rarely as possible. If this would become a scalability
    issue then the granularity could be reconsidered.

    > > - tpm_buf_append(buf, (u8 *) &value2, 4);
    > > + tpm_buf_append(buf, (u8 *)&value2, 4);
    >
    > Please try and avoid this sort of churn in patches that change things..

    It wasn't there on purpose. I do not know how these slipped. I can
    clean these up.

    > Jason

    /Jarkko

    \
     
     \ /
      Last update: 2017-01-03 05:01    [W:9.603 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site