Hi Gustavo,
>> so I took this patch back out of bluetooth-next before sending the pull
>> request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro
>> needs to complete first. Once that has concluded we can revisit if this
>> patch is still needed or if another solution has been found. Same as with
>> WiFi, these are not just one-shot calls where a memory allocation doesn’t
>> matter. We need this for random address resolution and thus there can be
>> many of the aes_cmac calls when seeing neighboring devices.
>
> Yeah. I agree.
>
> Based on Herbert's response to the discussion about SHASH_DESC_ON_STACK
> https://lkml.org/lkml/2018/3/27/300
>
> it seems it is feasible to fix that macro very easily. I will follow up on
> this.
>
> By the way, what is you opinion on replacing crypto_shash_descsize(ctx) with
> PAGE_SIZE / 8 in SHASH_DESC_ON_STACK?
>
> Does it work for you?
isn’t that just waste?
The macro itself is this.
#define SHASH_DESC_ON_STACK(shash, ctx) \
char __##shash##_desc[sizeof(struct shash_desc) + \
crypto_shash_descsize(ctx)] CRYPTO_MINALIGN_ATTR; \
struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
For AES-CMAC, we could always do this with a manual macro that gives us the
right size. However that is error prone if any internals change. I think what
has to happened that crypto_shash_decsize becomes something the compiler can
evaluate at compile time.
Regards
Marcel
