Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1570207062.3563.17.camel@HansenPartnership.com>
Subject: Re: [PATCH v3 2/2] tpm: Detach page allocation from tpm_buf
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        linux-integrity@vger.kernel.org
Cc:     Mimi Zohar <zohar@linux.ibm.com>,
        Jerry Snitselaar <jsnitsel@redhat.com>,
        Sumit Garg <sumit.garg@linaro.org>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Peter Huewe <peterhuewe@gmx.de>,
        Jason Gunthorpe <jgg@ziepe.ca>, Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        open list <linux-kernel@vger.kernel.org>
Date:   Fri, 04 Oct 2019 09:37:42 -0700
In-Reply-To: <20191003185103.26347-3-jarkko.sakkinen@linux.intel.com>
References: <20191003185103.26347-1-jarkko.sakkinen@linux.intel.com>
         <20191003185103.26347-3-jarkko.sakkinen@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 2019-10-03 at 21:51 +0300, Jarkko Sakkinen wrote:
> As has been seen recently, binding the buffer allocation and tpm_buf
> together is sometimes far from optimal.

Can you elaborate on this a bit more?  I must have missed the
discussion.

>  The buffer might come from the caller namely when tpm_send() is used
> by another subsystem. In addition we can stability in call sites w/o
> rollback (e.g. power events)>
> 
> Take allocation out of the tpm_buf framework and make it purely a
> wrapper for the data buffer.

What you're doing here is taking a single object with a single lifetime
and creating two separate objects with separate lifetimes and a
dependency.  The problem with doing that is that it always creates
subtle and hard to debug corner cases where the dependency gets
violated, so it's usually better to simplify the object lifetimes by
reducing the dependencies and combining as many dependent objects as
possible into a single object with one lifetime.  Bucking this trend
for a good reason is OK, but I think a better reason than "is sometimes
far from optimal" is needed.

James