s390/zcrypt: rework length information for dqap
authorHarald Freudenberger <freude@linux.ibm.com>
Tue, 14 Feb 2023 16:13:18 +0000 (17:13 +0100)
committerHeiko Carstens <hca@linux.ibm.com>
Mon, 20 Mar 2023 10:12:47 +0000 (11:12 +0100)
commit8794c5961394b7fb8a69f43eaad9566e5496c0c8
tree4d8874fc9fa4f920192095cb63c2cd2334a8d3e3
parent003d248fee72eb8d86aefaf3b6e47fe8acfda0b6
s390/zcrypt: rework length information for dqap

The inline ap_dqap function does not return the number of
bytes actually written into the message buffer. The calling
code inspects the AP message header to figure out what kind
of AP message has been received and pulls the length
information from this header. This processing may not work
correctly in cases where only a fragment of the reply is
received.

With this patch the ap_dqap inline function now returns
the number of actually written bytes in the *length parameter.
So the calling function has a chance to compare the number of
received bytes against what the AP message header length
field states. This is especially useful in cases where a
message could only get partially received.

The low level reply processing functions needed some rework
to be able to catch this new length information and compare
it the right way. The rework also deals with some situations
where until now the reply length was not correctly calculated
and/or set.

All this has been heavily tested as the modifications on
the reply length information may affect crypto load.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
arch/s390/include/asm/ap.h
drivers/s390/crypto/ap_bus.h
drivers/s390/crypto/ap_queue.c
drivers/s390/crypto/zcrypt_cex2c.c
drivers/s390/crypto/zcrypt_msgtype50.c
drivers/s390/crypto/zcrypt_msgtype6.c