Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: skb_cb corruption in ath10k
From:   Ben Greear <greearb@candelatech.com>
To:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        ath10k <ath10k@lists.infradead.org>
References: <86170a90-da2f-3227-d7e5-fe9486156705@candelatech.com>
Organization: Candela Technologies
Message-ID: <c79bb1d2-3571-4f3f-12a8-bce6701a7241@candelatech.com>
Date:   Thu, 24 Dec 2020 09:08:13 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <86170a90-da2f-3227-d7e5-fe9486156705@candelatech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-MW
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 12/21/20 3:55 PM, Ben Greear wrote:
> Hello,
> 
> I'm trying to figure out what changed in the last few kernels that is making:
> 
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)
>      /* why is code here all of a sudden */
> 
> in data frames in ath10k,
> when, to the best of my knowledge, nothing should be setting that up in the stack.
> 
> My guess is that something is stepping on the cb field somewhere in ath10k,
> but I am not sure where that might be at this point.
> 
> And it also appears mac80211 or maybe supplicant is setting the rate-inject flag on some mgt frames,
> but I think that is a separate concern at this point.
> 
> If anyone has any ideas of likely points, please let me know.

This issue was me being confused about how the ath10k skb_cb sits in
the same memory as the iee skb_cb.  I just needed to reorder the
ath10k-skb-cb struct a bit to not clobber the control.flags area.

I also see no reason not to natually pack that stuct so that the
pointers are 8-byte aligned.  Any idea why it is force-packed
currently instead of using proper padding?

Thanks,
Ben