[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202312131136.5C46279@keescook>
Date: Wed, 13 Dec 2023 11:37:10 -0800
From: Kees Cook <keescook@...omium.org>
To: Jeff Johnson <quic_jjohnson@...cinc.com>
Cc: Kalle Valo <kvalo@...nel.org>,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] wifi: ath10k: remove duplicate memset() in 10.4 TDLS
peer update
On Wed, Dec 13, 2023 at 11:36:08AM -0800, Jeff Johnson wrote:
> On 12/13/2023 11:16 AM, Kees Cook wrote:
> > On Wed, Dec 13, 2023 at 09:06:44AM -0800, Jeff Johnson wrote:
> >> In [1] it was identified that in ath10k_wmi_10_4_gen_tdls_peer_update()
> >> the memset(skb->data, 0, sizeof(*cmd)) is unnecessary since function
> >> ath10k_wmi_alloc_skb() already zeroes skb->data, so remove it.
> >
> > Is .gen_tdls_peer_update only ever called after a fresh allocation? It
> > wasn't obvious to me as I tried to follow the call paths. Is there harm
> > in leaving this?
>
> The only harm is a slight increase in code size and cpu cycles.
>
> However note the skb allocation is done within
> ath10k_wmi_10_4_gen_tdls_peer_update() itself, just before the code
> being removed:
> skb = ath10k_wmi_alloc_skb(ar, len);
> if (!skb)
> return ERR_PTR(-ENOMEM);
>
> And in ath10k_wmi_alloc_skb() we have:
> memset(skb->data, 0, round_len);
>
> So the memset() being removed is always redundant.
LOL. I see now. I missed that was was looking outside the function! :P
Reviewed-by: Kees Cook <keescook@...omium.org>
--
Kees Cook
Powered by blists - more mailing lists