Re: [PATCH v3 04/21] s390/ap/zcrypt: New xflag parameter

Harald Freudenberger
2025-04-09T13:46:09Z

On 2025-04-09 10:40, Holger Dengler wrote:
> On 27/03/2025 15:39, Harald Freudenberger wrote:
>> Introduce a new flag parameter for the both cprb send functions
>> zcrypt_send_cprb() and zcrypt_send_ep11_cprb(). This new
>> xflags parameter ("execution flags") shall be used to provide
>> execution hints and flags for this crypto request.
>>
>> There are two flags implemented to be used with these functions:
>> * ZCRYPT_XFLAG_USERSPACE - indicates to the lower layers that
>> all the ptrs address userspace. So when construction the ap msg
>> copy_from_user() is to be used. If this flag is NOT set, the ptrs
>> address kernel memory and thus memcpy() is to be used.
>> * ZCRYPT_XFLAG_NOMEMALLOC - indicates that this task must not
>> allocate memory which may be allocated with io operations.
>> For the zcrypt layer this limits the number of EP11 targets
>> to 16 APQNs. But as this flag is passed down the stack, it
>> may induce further restrictions.
>>
>> For the AP bus and zcrypt message layer this means:
>> * The ZCRYPT_XFLAG_USERSPACE is mapped to the already existing
>> bool variable "userspace" which is propagated to the zcrypt
>> proto implementations.
>> * The ZCRYPT_XFLAG_NOMEMALLOC results in setting the AP flag
>> AP_MSG_FLAG_MEMPOOL when the AP msg buffer is initialized.
>>
>> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
>> ---
>> drivers/s390/crypto/ap_bus.c | 6 +--
>> drivers/s390/crypto/ap_bus.h | 2 +-
>> drivers/s390/crypto/zcrypt_api.c | 76
>> +++++++++++++++------------
>> drivers/s390/crypto/zcrypt_api.h | 11 +++-
>> drivers/s390/crypto/zcrypt_ccamisc.c | 16 +++---
>> drivers/s390/crypto/zcrypt_ep11misc.c | 10 ++--
>> 6 files changed, 69 insertions(+), 52 deletions(-)
>>
> [...]
>> diff --git a/drivers/s390/crypto/zcrypt_api.c
>> b/drivers/s390/crypto/zcrypt_api.c
>> index ad09c5306e28..01cb72fed828 100644
>> --- a/drivers/s390/crypto/zcrypt_api.c
>> +++ b/drivers/s390/crypto/zcrypt_api.c
> [...]
>> @@ -1045,36 +1048,40 @@ static long _zcrypt_send_ep11_cprb(bool
>> userspace, struct ap_perms *perms,
>>
>> trace_s390_zcrypt_req(xcrb, TP_ZSENDEP11CPRB);
>>
>> - rc = ap_init_apmsg(&ap_msg, false);
>> + rc = ap_init_apmsg(&ap_msg, xflags & ZCRYPT_XFLAG_NOMEMALLOC ?
>> + AP_MSG_FLAG_MEMPOOL : 0);
>> if (rc)
>> goto out;
>>
>> target_num = (unsigned short)xcrb->targets_num;
>>
>> /* empty list indicates autoselect (all available targets) */
>> - targets = NULL;
>> + rc = -ENOMEM;
>> if (target_num != 0) {
>> struct ep11_target_dev __user *uptr;
>>
>> - targets = kcalloc(target_num, sizeof(*targets), GFP_KERNEL);
>> - if (!targets) {
>> - func_code = 0;
>> - rc = -ENOMEM;
>> + if (target_num <= ARRAY_SIZE(targetbuf)) {
>> + targets = targetbuf;
>> + } else if (xflags & ZCRYPT_XFLAG_NOMEMALLOC) {
>> goto out;
>> + } else {
>> + targets = kcalloc(target_num,
>> + sizeof(*targets), GFP_KERNEL);
>> + if (!targets)
>> + goto out;
>
> As discussed, this alloc&copy is only required in userspace path. If
> zcrypt_send_ep11_cprb() is called from userspace, the targets pointer
> can be used directly.

Done as discussed. There is now a new patch which changes this
code to not alloc and memcpy in case of kernel space. So with that
the 16 apqns stack buffer is not needed any more and thus will
vanish in v4 and so also this artificial limitation is gone as well.

changes