On Tue, May 13, 2014 at 08:50:00AM +0200, David Herrmann wrote: > Hi > > On Mon, May 12, 2014 at 8:43 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > > I looked into it again, the scenario where I assumed that this problem > > could occur didn't turn out to be true. I have no idea how this crash > > can occur. > > The only path that can set ah->caldata to NULL is through: > > ieee80211_hw_config() > ath9k_htc_config() > ath9k_htc_set_channel() > ath9k_hw_reset() > > This happens whenever IEEE80211_CONF_OFFCHANNEL is set. > > Now mac80211 is way to big for me to review right now and > ieee80211_hw_config() is used quite often. Given that the described > call-path does no synchronization against ath9k_htc_ani_work(), all > the callers of mac80211_hw_config(OFFCHANNEL) must guarantee that no > ani-work is running. Is that intentional? I cannot see any of those > functions calling into ath9k_htc_stop_ani(). This might of course be > implicit. > > One call-path I see is: > ieee80211_scan_cancel() > cancel_delayed_work() > > We cannot use cancel_delayed_work_sync() here due to locking issues. > However, this obviously races against any following > set_channel(OFFCHANNEL) request. > > If there's anything I can do to debug this, let me know. I tried > adding some printk()'s into the hot-path and it turns out to no longer > fail then. So this really seems to be a quite small race (given that a > bunch of simple printk()s is slow enough to work around it). David, Are you using USB devices? What is the PID/VID? I have not looked at HTC driver perspective. -Rajkumar -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
