Searched hist:"8794 c5961394b7fb8a69f43eaad9566e5496c0c8" (Results 1 – 6 of 6) sorted by relevance
| /linux/drivers/s390/crypto/ |
| H A D | zcrypt_cex2c.c | diff 8794c5961394b7fb8a69f43eaad9566e5496c0c8 Tue Feb 14 17:13:18 CET 2023 Harald Freudenberger <freude@linux.ibm.com> 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>
|
| H A D | zcrypt_msgtype50.c | diff 8794c5961394b7fb8a69f43eaad9566e5496c0c8 Tue Feb 14 17:13:18 CET 2023 Harald Freudenberger <freude@linux.ibm.com> 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>
|
| H A D | zcrypt_msgtype6.c | diff 8794c5961394b7fb8a69f43eaad9566e5496c0c8 Tue Feb 14 17:13:18 CET 2023 Harald Freudenberger <freude@linux.ibm.com> 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>
|
| H A D | ap_queue.c | diff 8794c5961394b7fb8a69f43eaad9566e5496c0c8 Tue Feb 14 17:13:18 CET 2023 Harald Freudenberger <freude@linux.ibm.com> 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>
|
| H A D | ap_bus.h | diff 8794c5961394b7fb8a69f43eaad9566e5496c0c8 Tue Feb 14 17:13:18 CET 2023 Harald Freudenberger <freude@linux.ibm.com> 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>
|
| /linux/arch/s390/include/asm/ |
| H A D | ap.h | diff 8794c5961394b7fb8a69f43eaad9566e5496c0c8 Tue Feb 14 17:13:18 CET 2023 Harald Freudenberger <freude@linux.ibm.com> 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>
|