[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2849751f-ff26-193e-f15e-4d7d5f8525a7@infineon.com>
Date: Mon, 11 Feb 2019 16:05:39 +0100
From: Alexander Steffen <Alexander.Steffen@...ineon.com>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Stefan Berger <stefanb@...ux.ibm.com>
CC: <linux-integrity@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-security-module@...r.kernel.org>,
Peter Huewe <PeterHuewe@....de>,
Jason Gunthorpe <jgg@...pe.ca>,
Stefan Berger <stefanb@...ux.vnet.ibm.com>,
<stable@...r.kernel.org>
Subject: Re: [PATCH v4 1/2] tpm: Unify the send callback behaviour
On 08.02.2019 20:00, Jarkko Sakkinen wrote:
> On Fri, Feb 08, 2019 at 01:12:34PM -0500, Stefan Berger wrote:
>> On 2/8/19 1:08 PM, Jarkko Sakkinen wrote:
>>> The send() callback should never return length as it does not in every
>>> driver except tpm_crb in the success case. The reason is that the main
>>> transmit functionality only cares about whether the transmit was
>>> successful or not and ignores the count completely.
>>>
>>> Cc: stable@...r.kernel.org
>>> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
>>
>> Reviewed-by: Stefan Berger <stefanb@...ux.ibm.com>
>>
>> Let me know when you put it into your tree, I'll give it a spin while I am
>> at it. :-)
>
> Thank you Stefan! I also add your suggested-by to the first commit
> because you pointed out the problem.
>
> It all looks now legit, but just in case I'll add a check for the return
> value to tpm_try_transmit() and a warning if it is not zero in the
> success case (and after that zeroing of rc).
>
> That check can be removed when I do v5.3 pull request. That should
> enough window to catch any potential issues and check will ensure that
> kernel won't fail even there was something forgotten.
>
> Alexander, I'll push this version now to the master and next with the
> additional check described in this commit, but will add your tags
> after you have time to test.
I ran all tests again and everything works now as expected :)
Tested-by: Alexander Steffen <Alexander.Steffen@...ineon.com>
Alexander
Powered by blists - more mailing lists