From: Harald Freudenberger <freude@linux.ibm.com>
To: Holger Dengler <dengler@linux.ibm.com>
Cc: ifranzki@linux.ibm.com, fcallies@linux.ibm.com,
hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com,
linux-s390@vger.kernel.org, herbert@gondor.apana.org.au
Subject: Re: [PATCH v2 10/20] s390/zcrypt/pkey: Rework cca findcard() implementation and callers
Date: Tue, 25 Mar 2025 14:02:20 +0100 [thread overview]
Message-ID: <2d4d5cb7097995907fd862bad86e4e10@linux.ibm.com> (raw)
In-Reply-To: <2fb000bd-1764-4fef-9d6b-fa1ee705da6b@linux.ibm.com>
On 2025-03-19 18:58, Holger Dengler wrote:
> On 04/03/2025 18:21, Harald Freudenberger wrote:
>> Rework the memory usage of the cca findcard() implementation:
>> - findcard does not allocate memory for the list of apqns
>> any more.
>> - the callers are now responsible to provide an array of
>> apqns to store the matching apqns into.
>>
>> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
>
> See my comments below.
>
>> ---
>> drivers/s390/crypto/pkey_cca.c | 25 +++++++++++--------------
>> drivers/s390/crypto/zcrypt_ccamisc.c | 18 ++++--------------
>> drivers/s390/crypto/zcrypt_ccamisc.h | 12 +++++-------
>> 3 files changed, 20 insertions(+), 35 deletions(-)
>>
> [...]
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c
>> b/drivers/s390/crypto/zcrypt_ccamisc.c
>> index 65b4cdb9b478..d3b093dcdf30 100644
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> [...]
>> @@ -2006,17 +1999,14 @@ int cca_findcard2(u32 **apqns, u32 *nr_apqns,
>> u16 cardnr, u16 domain,
>> continue;
>> }
>> /* apqn passed all filtering criterons, add to the array */
>> - if (_nr_apqns < 256)
>> - _apqns[_nr_apqns++] = (((u16)card) << 16) | ((u16)dom);
>> + if (_nr_apqns < *nr_apqns)
>> + apqns[_nr_apqns++] = (((u16)card) << 16) | ((u16)dom);
>> }
>>
>> /* nothing found ? */
>> if (!_nr_apqns) {
>> - kfree(_apqns);
>> rc = -ENODEV;
>
> In my opinion, the -ENODEV return value can be completely dropped. For
> the caller it should be sufficient to check for nr_apqns == 0.
>
>> } else {
>> - /* no re-allocation, simple return the _apqns array */
>> - *apqns = _apqns;
>> *nr_apqns = _nr_apqns;
>
> Please update *nr_apqns unconditionally.
>
>> rc = 0;
>> }
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.h
>> b/drivers/s390/crypto/zcrypt_ccamisc.h
>> index 273edf2bb036..bed647a42eb2 100644
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.h
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.h
>> @@ -229,14 +229,12 @@ int cca_findcard(const u8 *key, u16 *pcardnr,
>> u16 *pdomain, int verify);
>> * cur_mkvp or old_mkvp values of the apqn are used.
>> * The mktype determines which set of master keys to use:
>> * 0 = AES_MK_SET - AES MK set, 1 = APKA MK_SET - APKA MK set
>> - * The array of apqn entries is allocated with kmalloc and returned
>> in *apqns;
>> - * the number of apqns stored into the list is returned in *nr_apqns.
>> One apqn
>> - * entry is simple a 32 bit value with 16 bit cardnr and 16 bit
>> domain nr and
>> - * may be casted to struct pkey_apqn. The return value is either 0
>> for success
>> - * or a negative errno value. If no apqn meeting the criteria is
>> found,
>> - * -ENODEV is returned.
>> + * The caller should set *nr_apqns to the nr of elements available in
>> *apqns.
>> + * On return *nr_apqns is then updated with the nr of apqns filled
>> into *apqns.
>> + * The return value is either 0 for success or a negative errno
>> value.
>> + * If no apqn meeting the criteria is found, -ENODEV is returned.
>
> Why not just return nr_apqns == 0 to indicate, that no matching device
> has been found? Anyhow, even if you would stay with the -ENODEV return
> value, *nr_apqns should be updated in any case.
>
>> */
>> -int cca_findcard2(u32 **apqns, u32 *nr_apqns, u16 cardnr, u16 domain,
>> +int cca_findcard2(u32 *apqns, u32 *nr_apqns, u16 cardnr, u16 domain,
>> int minhwtype, int mktype, u64 cur_mkvp, u64 old_mkvp,
>> int verify);
>>
I changed this to unconditionally always update *nr_apqns.
But I'd like to stay with the -ENODEV in case 0 apqns have been found.
There is code using this returncode (which then also would need
reworked).
next prev parent reply other threads:[~2025-03-25 13:02 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 17:20 [PATCH v2 00/20] AP bus/zcrypt/pkey/paes no-mem-alloc patches Harald Freudenberger
2025-03-04 17:20 ` [PATCH v2 01/20] s390/ap: Move response_type struct into ap_msg struct Harald Freudenberger
2025-03-17 9:38 ` Holger Dengler
2025-03-24 14:34 ` Harald Freudenberger
2025-03-04 17:20 ` [PATCH v2 02/20] s390/ap/zcrypt: Rework AP message buffer allocation Harald Freudenberger
2025-03-17 13:57 ` Holger Dengler
2025-03-04 17:20 ` [PATCH v2 03/20] s390/ap: Introduce ap message buffer pool Harald Freudenberger
2025-03-17 16:14 ` Holger Dengler
2025-03-24 14:41 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 04/20] s390/ap/zcrypt: New xflag parameter and extension of the ap msg flags Harald Freudenberger
2025-03-18 12:16 ` Holger Dengler
2025-03-24 15:52 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 05/20] s390/zcrypt: Introduce cprb mempool for cca misc functions Harald Freudenberger
2025-03-18 14:16 ` Holger Dengler
2025-03-25 8:26 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 06/20] s390/zcrypt: Introduce cprb mempool for ep11 " Harald Freudenberger
2025-03-18 15:16 ` Holger Dengler
2025-03-25 8:36 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 07/20] s390/zcrypt: Rework zcrypt function zcrypt_device_status_mask_ext Harald Freudenberger
2025-03-19 11:03 ` Holger Dengler
2025-03-25 9:24 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 08/20] s390/zcrypt: Introduce pre-allocated device status array for cca misc Harald Freudenberger
2025-03-19 14:31 ` Holger Dengler
2025-03-25 10:51 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 09/20] s390/zcrypt: Introduce pre-allocated device status array for ep11 misc Harald Freudenberger
2025-03-19 18:02 ` Holger Dengler
2025-03-25 11:09 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 10/20] s390/zcrypt/pkey: Rework cca findcard() implementation and callers Harald Freudenberger
2025-03-19 17:58 ` Holger Dengler
2025-03-25 13:02 ` Harald Freudenberger [this message]
2025-03-04 17:21 ` [PATCH v2 11/20] s390/zcrypt/pkey: Rework ep11 " Harald Freudenberger
2025-03-20 8:30 ` Holger Dengler
2025-03-25 13:12 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 12/20] s390/zcrypt: Rework cca misc functions kmallocs to use the cprb mempool Harald Freudenberger
2025-03-20 9:31 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 13/20] s390/zcrypt: Add small mempool for cca info list entries Harald Freudenberger
2025-03-20 14:34 ` Holger Dengler
2025-03-25 13:32 ` Harald Freudenberger
2025-03-20 16:05 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 14/20] s390/zcrypt: Locate ep11_domain_query_info onto the stack instead of kmalloc Harald Freudenberger
2025-03-20 14:41 ` Holger Dengler
2025-03-25 14:04 ` Harald Freudenberger
2025-03-04 17:21 ` [PATCH v2 15/20] s390/zcrypt: Rework ep11 misc functions to use cprb mempool Harald Freudenberger
2025-03-20 15:18 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 16/20] s390/zcrypt: Add small mempool for ep11 card info list entries Harald Freudenberger
2025-03-20 16:09 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 17/20] s390/pkey: Rework CCA pkey handler to use stack for small memory allocs Harald Freudenberger
2025-03-21 9:05 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 18/20] s390/pkey: Rework EP11 " Harald Freudenberger
2025-03-21 9:06 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 19/20] s390/zcrypt/pkey: Provide and pass xflags within pkey and zcrypt layers Harald Freudenberger
2025-03-20 16:30 ` Holger Dengler
2025-03-04 17:21 ` [PATCH v2 20/20] s390/pkey/crypto: Introduce xflags param for pkey in-kernel API Harald Freudenberger
2025-03-20 16:34 ` Holger Dengler
2025-03-20 16:40 ` [PATCH v2 00/20] AP bus/zcrypt/pkey/paes no-mem-alloc patches Holger Dengler
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=2d4d5cb7097995907fd862bad86e4e10@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=dengler@linux.ibm.com \
--cc=fcallies@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.