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;
To:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        ath10k <ath10k@lists.infradead.org>
From:   Ben Greear <greearb@candelatech.com>
Subject: skb_cb corruption in ath10k
Organization: Candela Technologies
Message-ID: <86170a90-da2f-3227-d7e5-fe9486156705@candelatech.com>
Date:   Mon, 21 Dec 2020 15:55:32 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-MW
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com