[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bdabfb74-ea4f-4455-bb4c-1d93977393ea@quicinc.com>
Date: Wed, 13 Dec 2023 11:36:08 -0800
From: Jeff Johnson <quic_jjohnson@...cinc.com>
To: Kees Cook <keescook@...omium.org>
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 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.
/jeff
Powered by blists - more mailing lists