[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu_eS-C84rH_MLYy--ivC0a99wwJvNDLhETfrBkYXW-XpA@mail.gmail.com>
Date: Fri, 14 Oct 2016 14:13:08 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Andy Lutomirski <luto@...capital.net>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
"<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
"<linux-wireless@...r.kernel.org>" <linux-wireless@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jouni Malinen <j@...fi>
Subject: Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
On 14 October 2016 at 14:10, Johannes Berg <johannes@...solutions.net> wrote:
>
>> So use kzalloc
>
> Do we really need kzalloc()? We have things on the stack right now, and
> don't initialize, so surely we don't really need to zero things?
>
>> This only addresses one half of the problem. The other problem, i.e.,
>> the fact that the aad[] array lives on the stack of the caller, is
>> handled adequately imo by the change proposed by Johannes.
>
> But if we allocate things anyway, is it worth expending per-CPU buffers
> on these?
>
Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer, and
copies aad[] into it as well
That does not help the other algos though
Powered by blists - more mailing lists