From: Holger Dengler <dengler@linux.ibm.com>
To: Harald Freudenberger <freude@linux.ibm.com>,
ifranzki@linux.ibm.com, fcallies@linux.ibm.com
Cc: linux-s390@vger.kernel.org, herbert@gondor.apana.org.au
Subject: Re: [PATCH v1 01/20] s390/ap: Move response_type struct into ap_msg struct
Date: Mon, 24 Feb 2025 16:23:13 +0100 [thread overview]
Message-ID: <4e7052e5-2319-42f8-a9f0-ca59227a2f10@linux.ibm.com> (raw)
In-Reply-To: <20250223095459.43058-2-freude@linux.ibm.com>
On 23/02/2025 10:54, Harald Freudenberger wrote:
> Move the very small response_type struct into struct ap_msg.
> So there is no need to kmalloc this tiny struct with each
> ap message preparation.
I understand the intention for this patch, but in my opinion the layering concept between ap and zcrypt is violated by defining the response-type as part of the ap message struct. But I don't have any better solution, so for the moment you may leave it as is.
>
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
> ---
> drivers/s390/crypto/ap_bus.h | 12 ++-
> drivers/s390/crypto/zcrypt_msgtype50.c | 22 +++---
> drivers/s390/crypto/zcrypt_msgtype6.c | 101 ++++++++++---------------
> 3 files changed, 59 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h
> index f4622ee4d894..a5d8f805625f 100644
> --- a/drivers/s390/crypto/ap_bus.h
> +++ b/drivers/s390/crypto/ap_bus.h
> @@ -214,6 +214,15 @@ struct ap_queue {
>
> typedef enum ap_sm_wait (ap_func_t)(struct ap_queue *queue);
>
> +struct ap_response_type {
> + struct completion work;
> + int type;
> +};
> +
> +#define CEXXC_RESPONSE_TYPE_ICA 1
> +#define CEXXC_RESPONSE_TYPE_XCRB 2
> +#define CEXXC_RESPONSE_TYPE_EP11 3
> +
I would leave the type defines in the zcrypt_msgtype50.c.
> struct ap_message {
> struct list_head list; /* Request queueing. */
> unsigned long psmid; /* Message id. */
> @@ -222,7 +231,7 @@ struct ap_message {
> size_t bufsize; /* allocated msg buffer size */
> u16 flags; /* Flags, see AP_MSG_FLAG_xxx */
> int rc; /* Return code for this message */
> - void *private; /* ap driver private pointer. */
> + struct ap_response_type response;
I don't like this change. The completion and the type are both message-type related. That means, this change pulls messate-type related data definitions into the ap-layer. On the other hand, I have currently no idea how this can be solved.
> /* receive is called from tasklet context */
> void (*receive)(struct ap_queue *, struct ap_message *,
> struct ap_message *);
> @@ -250,7 +259,6 @@ static inline void ap_init_message(struct ap_message *ap_msg)
> static inline void ap_release_message(struct ap_message *ap_msg)
> {
> kfree_sensitive(ap_msg->msg);
> - kfree_sensitive(ap_msg->private);
As far as I can see, the kfree_sensitive() was not really required, as this only contains the type and the completion, but no sensitive data, right?
If the assumption is true, the change is ok (if not, we should replace it with a memzero_explicit()).
> @@ -454,25 +454,24 @@ static long zcrypt_msgtype50_modexpo(struct zcrypt_queue *zq,
> struct ica_rsa_modexpo *mex,
> struct ap_message *ap_msg)
> {
> - struct completion work;
> int rc;
>
> ap_msg->bufsize = MSGTYPE50_CRB3_MAX_MSG_SIZE;
> - ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
> + if (!ap_msg->msg)
> + ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
This change will be removed by the next patch in the series. Please drop it. There are other occurances later in the code, see my further comments.
> if (!ap_msg->msg)
> return -ENOMEM;
> ap_msg->receive = zcrypt_msgtype50_receive;
> ap_msg->psmid = (((unsigned long)current->pid) << 32) +
> atomic_inc_return(&zcrypt_step);
> - ap_msg->private = &work;
> rc = ICAMEX_msg_to_type50MEX_msg(zq, ap_msg, mex);
> if (rc)
> goto out;
> - init_completion(&work);
> + init_completion(&ap_msg->response.work);
> rc = ap_queue_message(zq->queue, ap_msg);
> if (rc)
> goto out;
> - rc = wait_for_completion_interruptible(&work);
> + rc = wait_for_completion_interruptible(&ap_msg->response.work);
> if (rc == 0) {
> rc = ap_msg->rc;
> if (rc == 0)
[...]
> @@ -504,25 +502,24 @@ static long zcrypt_msgtype50_modexpo_crt(struct zcrypt_queue *zq,
> struct ica_rsa_modexpo_crt *crt,
> struct ap_message *ap_msg)
> {
> - struct completion work;
> int rc;
>
> ap_msg->bufsize = MSGTYPE50_CRB3_MAX_MSG_SIZE;
> - ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
> + if (!ap_msg->msg)
> + ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
Same here, please drop it.
> if (!ap_msg->msg)
> return -ENOMEM;
> ap_msg->receive = zcrypt_msgtype50_receive;
> ap_msg->psmid = (((unsigned long)current->pid) << 32) +
> atomic_inc_return(&zcrypt_step);
> - ap_msg->private = &work;
> rc = ICACRT_msg_to_type50CRT_msg(zq, ap_msg, crt);
> if (rc)
> goto out;
> - init_completion(&work);
> + init_completion(&ap_msg->response.work);
> rc = ap_queue_message(zq->queue, ap_msg);
> if (rc)
> goto out;
> - rc = wait_for_completion_interruptible(&work);
> + rc = wait_for_completion_interruptible(&ap_msg->response.work);
> if (rc == 0) {
> rc = ap_msg->rc;
> if (rc == 0)
[...]
> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index b64c9d9fc613..21ee311cf33d 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c
> @@ -31,15 +31,6 @@
>
> #define CEIL4(x) ((((x) + 3) / 4) * 4)
>
> -struct response_type {
> - struct completion work;
> - int type;
> -};
> -
> -#define CEXXC_RESPONSE_TYPE_ICA 0
> -#define CEXXC_RESPONSE_TYPE_XCRB 1
> -#define CEXXC_RESPONSE_TYPE_EP11 2
> -
Please define the message types here (see my previous comment).
> MODULE_AUTHOR("IBM Corporation");
> MODULE_DESCRIPTION("Cryptographic Coprocessor (message type 6), " \
> "Copyright IBM Corp. 2001, 2023");
[...]
> @@ -1061,28 +1046,26 @@ static long zcrypt_msgtype6_modexpo_crt(struct zcrypt_queue *zq,
> * Prepare a CCA AP msg: fetch the required data from userspace,
> * prepare the AP msg, fill some info into the ap_message struct,
> * extract some data from the CPRB and give back to the caller.
> - * This function allocates memory and needs an ap_msg prepared
> - * by the caller with ap_init_message(). Also the caller has to
> - * make sure ap_release_message() is always called even on failure.
> + * This function may allocate memory if the ap_msg msg buffer is
> + * not preallocated and needs an ap_msg prepared by the caller
> + * with ap_init_message(). Also the caller has to make sure
> + * ap_release_message() is always called even on failure.
Please move this change to the patch, which makes the allocation optional.
> */
> int prep_cca_ap_msg(bool userspace, struct ica_xcRB *xcrb,
> struct ap_message *ap_msg,
> unsigned int *func_code, unsigned short **dom)
> {
> - struct response_type resp_type = {
> - .type = CEXXC_RESPONSE_TYPE_XCRB,
> - };
> + struct ap_response_type *resp_type = &ap_msg->response;
>
> ap_msg->bufsize = atomic_read(&ap_max_msg_size);
> - ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
> + if (!ap_msg->msg)
> + ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
Please drop the kmalloc change.
> if (!ap_msg->msg)
> return -ENOMEM;
> ap_msg->receive = zcrypt_msgtype6_receive;
> ap_msg->psmid = (((unsigned long)current->pid) << 32) +
> atomic_inc_return(&zcrypt_step);
> - ap_msg->private = kmemdup(&resp_type, sizeof(resp_type), GFP_KERNEL);
> - if (!ap_msg->private)
> - return -ENOMEM;
> + resp_type->type = CEXXC_RESPONSE_TYPE_XCRB;
> return xcrb_msg_to_type6cprb_msgx(userspace, ap_msg, xcrb, func_code, dom);
> }
>
[...]
> @@ -1158,28 +1141,26 @@ static long zcrypt_msgtype6_send_cprb(bool userspace, struct zcrypt_queue *zq,
> * Prepare an EP11 AP msg: fetch the required data from userspace,
> * prepare the AP msg, fill some info into the ap_message struct,
> * extract some data from the CPRB and give back to the caller.
> - * This function allocates memory and needs an ap_msg prepared
> - * by the caller with ap_init_message(). Also the caller has to
> - * make sure ap_release_message() is always called even on failure.
> + * This function may allocate memory if the ap_msg msg buffer is
> + * not preallocated and needs an ap_msg prepared by the caller
> + * with ap_init_message(). Also the caller has to make sure
> + * ap_release_message() is always called even on failure.
Please move this change to the patch, which makes the allocation optional.
> */
> int prep_ep11_ap_msg(bool userspace, struct ep11_urb *xcrb,
> struct ap_message *ap_msg,
> unsigned int *func_code, unsigned int *domain)
> {
> - struct response_type resp_type = {
> - .type = CEXXC_RESPONSE_TYPE_EP11,
> - };
> + struct ap_response_type *resp_type = &ap_msg->response;
>
> ap_msg->bufsize = atomic_read(&ap_max_msg_size);
> - ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
> + if (!ap_msg->msg)
> + ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
Please drop the kmalloc change.
> if (!ap_msg->msg)
> return -ENOMEM;
> ap_msg->receive = zcrypt_msgtype6_receive_ep11;
> ap_msg->psmid = (((unsigned long)current->pid) << 32) +
> atomic_inc_return(&zcrypt_step);
> - ap_msg->private = kmemdup(&resp_type, sizeof(resp_type), GFP_KERNEL);
> - if (!ap_msg->private)
> - return -ENOMEM;
> + resp_type->type = CEXXC_RESPONSE_TYPE_EP11;
> return xcrb_msg_to_type6_ep11cprb_msgx(userspace, ap_msg, xcrb,
> func_code, domain);
> }
[...]
> @@ -1279,20 +1260,18 @@ static long zcrypt_msgtype6_send_ep11_cprb(bool userspace, struct zcrypt_queue *
> int prep_rng_ap_msg(struct ap_message *ap_msg, int *func_code,
> unsigned int *domain)
> {
> - struct response_type resp_type = {
> - .type = CEXXC_RESPONSE_TYPE_XCRB,
> - };
> + struct ap_response_type *resp_type = &ap_msg->response;
>
> ap_msg->bufsize = AP_DEFAULT_MAX_MSG_SIZE;
> - ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
> + if (!ap_msg->msg)
> + ap_msg->msg = kmalloc(ap_msg->bufsize, GFP_KERNEL);
Please drop the kmalloc change.
> if (!ap_msg->msg)
> return -ENOMEM;
> ap_msg->receive = zcrypt_msgtype6_receive;
> ap_msg->psmid = (((unsigned long)current->pid) << 32) +
> atomic_inc_return(&zcrypt_step);
> - ap_msg->private = kmemdup(&resp_type, sizeof(resp_type), GFP_KERNEL);
> - if (!ap_msg->private)
> - return -ENOMEM;
> +
> + resp_type->type = CEXXC_RESPONSE_TYPE_XCRB;
>
> rng_type6cprb_msgx(ap_msg, ZCRYPT_RNG_BUFFER_SIZE, domain);
>
[...]
--
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@linux.ibm.com
next prev parent reply other threads:[~2025-02-24 15:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-23 9:54 [PATCH v1 00/20] AP bus/zcrypt/pkey/paes no-mem-alloc patches Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 01/20] s390/ap: Move response_type struct into ap_msg struct Harald Freudenberger
2025-02-24 15:23 ` Holger Dengler [this message]
2025-02-25 7:39 ` Holger Dengler
2025-02-25 8:56 ` Harald Freudenberger
2025-02-25 9:22 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 02/20] s390/ap/zcrypt: Rework AP message buffer allocation Harald Freudenberger
2025-02-25 8:12 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 03/20] s390/ap: Introduce ap message buffer pool Harald Freudenberger
2025-02-25 13:52 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 04/20] s390/zcrypt: Rework zcrypt layer to support new flag NOMEMALLOC Harald Freudenberger
2025-02-27 8:21 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 05/20] s390/zcrypt: Introduce cprb mempool for cca misc functions Harald Freudenberger
2025-03-03 8:07 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 06/20] s390/zcrypt: Introduce cprb mempool for ep11 " Harald Freudenberger
2025-03-03 8:29 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 07/20] s390/zcrypt: New zcrypt function zcrypt_device_status_mask_ext2 Harald Freudenberger
2025-02-27 11:34 ` Holger Dengler
2025-02-23 9:54 ` [PATCH v1 08/20] s390/zcrypt: Introduce pre-allocated device status array for cca misc Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 09/20] s390/zcrypt: Introduce pre-allocated device status array for ep11 misc Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 10/20] s390/zcrypt/pkey: Rework cca findcard() implementation and callers Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 11/20] s390/zcrypt/pkey: Rework ep11 " Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 12/20] s390/zcrypt: Rework cca misc functions kmallocs to use the cprb mempool Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 13/20] s390/zcrypt: Add small mempool for cca info list entries Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 14/20] s390/zcrypt: Locate ep11_domain_query_info onto the stack instead of kmalloc Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 15/20] s390/zcrypt: Rework ep11 misc functions to use cprb mempool Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 16/20] s390/zcrypt: Add small mempool for ep11 card info list entries Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 17/20] s390/pkey: Rework CCA pkey handler to use stack for small memory allocs Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 18/20] s390/pkey: Rework EP11 " Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 19/20] s390/zcrypt/pkey: Provide and pass xflags within pkey and zcrypt layers Harald Freudenberger
2025-02-23 9:54 ` [PATCH v1 20/20] s390/pkey/crypto: Introduce xflags param for pkey in-kernel API Harald Freudenberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e7052e5-2319-42f8-a9f0-ca59227a2f10@linux.ibm.com \
--to=dengler@linux.ibm.com \
--cc=fcallies@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=ifranzki@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox