While the original code is valid, it is not the obvious choice for the
sizeof() call and in preparation to limit the scope of the list iterator
variable the sizeof should be changed to the size of the variable
being allocated.
Signed-off-by: Jakob Koschel <[email protected]>
---
drivers/s390/crypto/zcrypt_card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/zcrypt_card.c b/drivers/s390/crypto/zcrypt_card.c
index 3e259befd30a..fcbd537530e8 100644
--- a/drivers/s390/crypto/zcrypt_card.c
+++ b/drivers/s390/crypto/zcrypt_card.c
@@ -90,7 +90,7 @@ static ssize_t online_store(struct device *dev,
list_for_each_entry(zq, &zc->zqueues, list)
maxzqs++;
if (maxzqs > 0)
- zq_uelist = kcalloc(maxzqs + 1, sizeof(zq), GFP_ATOMIC);
+ zq_uelist = kcalloc(maxzqs + 1, sizeof(*zq_uelist), GFP_ATOMIC);
list_for_each_entry(zq, &zc->zqueues, list)
if (zcrypt_queue_force_online(zq, online))
if (zq_uelist) {
base-commit: 34e047aa16c0123bbae8e2f6df33e5ecc1f56601
--
2.25.1
> On 21. Mar 2022, at 10:26, hfreude <[email protected]> wrote:
>
> On 2022-03-19 21:35, Jakob Koschel wrote:
>> While the original code is valid, it is not the obvious choice for the
>> sizeof() call and in preparation to limit the scope of the list iterator
>> variable the sizeof should be changed to the size of the variable
>> being allocated.
>> Signed-off-by: Jakob Koschel <[email protected]>
>> ---
>> drivers/s390/crypto/zcrypt_card.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/drivers/s390/crypto/zcrypt_card.c
>> b/drivers/s390/crypto/zcrypt_card.c
>> index 3e259befd30a..fcbd537530e8 100644
>> --- a/drivers/s390/crypto/zcrypt_card.c
>> +++ b/drivers/s390/crypto/zcrypt_card.c
>> @@ -90,7 +90,7 @@ static ssize_t online_store(struct device *dev,
>> list_for_each_entry(zq, &zc->zqueues, list)
>> maxzqs++;
>> if (maxzqs > 0)
>> - zq_uelist = kcalloc(maxzqs + 1, sizeof(zq), GFP_ATOMIC);
>> + zq_uelist = kcalloc(maxzqs + 1, sizeof(*zq_uelist), GFP_ATOMIC);
>> list_for_each_entry(zq, &zc->zqueues, list)
>> if (zcrypt_queue_force_online(zq, online))
>> if (zq_uelist) {
>> base-commit: 34e047aa16c0123bbae8e2f6df33e5ecc1f56601
>> --
>> 2.25.1
> Thanks Jakob, add my Reviewed-by: Harald Freudenberger <[email protected]>
> Which way is this patch going to be integrated into the kernel ?
> Usually I pick this and push it into s390 and on the next merge window it will
> get merged into Linus Torvalds kernel tree.
> However, sounds like you are about to clean up the kernel in preparation for the
> changes related to the double linked list api. So maybe you have a patch series
> which will go into the kernel by another way ?
> Waiting for an answer, Thanks
>
CC'd Greg KH (in case he has some input) but my assumption is that this just goes
the normal way through your s390 tree. Most of this cleanup is not in a hurry so
getting it into the next merge window should be fine.
Jakob
On Mon, Mar 21, 2022 at 01:16:52PM +0100, Jakob Koschel wrote:
>
> > On 21. Mar 2022, at 10:26, hfreude <[email protected]> wrote:
> >
> > On 2022-03-19 21:35, Jakob Koschel wrote:
> >> While the original code is valid, it is not the obvious choice for the
> >> sizeof() call and in preparation to limit the scope of the list iterator
> >> variable the sizeof should be changed to the size of the variable
> >> being allocated.
> >> Signed-off-by: Jakob Koschel <[email protected]>
> >> ---
> >> drivers/s390/crypto/zcrypt_card.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> diff --git a/drivers/s390/crypto/zcrypt_card.c
> >> b/drivers/s390/crypto/zcrypt_card.c
> >> index 3e259befd30a..fcbd537530e8 100644
> >> --- a/drivers/s390/crypto/zcrypt_card.c
> >> +++ b/drivers/s390/crypto/zcrypt_card.c
> >> @@ -90,7 +90,7 @@ static ssize_t online_store(struct device *dev,
> >> list_for_each_entry(zq, &zc->zqueues, list)
> >> maxzqs++;
> >> if (maxzqs > 0)
> >> - zq_uelist = kcalloc(maxzqs + 1, sizeof(zq), GFP_ATOMIC);
> >> + zq_uelist = kcalloc(maxzqs + 1, sizeof(*zq_uelist), GFP_ATOMIC);
> >> list_for_each_entry(zq, &zc->zqueues, list)
> >> if (zcrypt_queue_force_online(zq, online))
> >> if (zq_uelist) {
> >> base-commit: 34e047aa16c0123bbae8e2f6df33e5ecc1f56601
> >> --
> >> 2.25.1
> > Thanks Jakob, add my Reviewed-by: Harald Freudenberger <[email protected]>
> > Which way is this patch going to be integrated into the kernel ?
> > Usually I pick this and push it into s390 and on the next merge window it will
> > get merged into Linus Torvalds kernel tree.
> > However, sounds like you are about to clean up the kernel in preparation for the
> > changes related to the double linked list api. So maybe you have a patch series
> > which will go into the kernel by another way ?
> > Waiting for an answer, Thanks
> >
>
> CC'd Greg KH (in case he has some input) but my assumption is that this just goes
> the normal way through your s390 tree. Most of this cleanup is not in a hurry so
> getting it into the next merge window should be fine.
Normal way is fine.
thanks,
greg k-h