On Thu, Jun 25, 2020 at 05:27:50PM -0400, Stefan Berger wrote:
On 6/25/20 5:25 PM, Jarkko Sakkinen wrote:Now that you mentioned PPC64 in some other email that would make this a
On Thu, Jun 25, 2020 at 08:41:18AM -0400, Stefan Berger wrote:Ok, so distros will have to backport it.
On 6/25/20 12:38 AM, Jarkko Sakkinen wrote:It's not a regression.
Re-allocate context and session buffers when needed. Scale them in pageYou don't want to try a fixes tag? None of the previous versions of this
increments so that the reallocation is only seldomly required, and thus
causes minimal stress to the system. Add a static maximum limit of four
pages for buffer sizes.
Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
Suggested-by: Stefan Berger <stefanb@xxxxxxxxxxxxx>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
code will work with newer versions of the TPM 2 then...
regression since x86 provides less space for keys than PPC64.
I studied PPC64 a bit and it actually allows max 256 kB page size, which
is too much for us, given that there is no accounting implemented for
TPM spaces (so far, should be done eventually).
So to summarize: 0 the idea would decrease the limit on PPC64 and
increase it on ther arch's. `
Dynamic scaling is over to top for fixing the issue, which means that I
will just define static size of 16 kB for the buffer. We can reconsider
it if we hit the roof again.
/Jarkko