[OpenWrt-Devel] [PATCH] mac80211: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable bit.
yszhou4tech at gmail.com
Mon Aug 25 03:55:28 EDT 2014
On 25 August 2014 14:24, John Crispin <blogic at openwrt.org> wrote:
> On 25/08/2014 05:29, Yousong Zhou wrote:
>> +- /* +- * Upload beacon to the H/W. This is only required on
>> +- * USB devices. PCI devices fetch beacons periodically. +-
>> */ +- if (rt2x00_is_usb(rt2x00dev)) +-
>> rt2x00queue_update_beacon(rt2x00dev, vif); ++
>> rt2x00queue_update_beacon(rt2x00dev, vif); +
> this bit looks like someone intentionally added the comment to prevent
> us from removing the if () clause. are you sure that removing it is
> correct ?
As I deem myself not yet equipped with the necessary knowledge of all
three interface types of rt2x00 device, I should at this point say
"no, I am not sure". It's based on the following observation.
In previous patch I only changed that condition into
to exclude mt7620a from this "pci" group and it did silence the
WARNING initially reported in #17032.
Later I found that wasn't enough, the WARNING could still be triggered
randomly by command like `iw dev wlan0 scan`. Then I found
rt2x00queue_update_beacon() was called unconditionally by
rt2800mmio_tbtt_tasklet() which was registered as callback function
for both rt2800soc and rt2800pci. If the comment that "PCI devices
fetch beacons periodically" refers to tasklet serving interrupts, then
the same mechanism also applies to SoC devices.
ENTRY_BCN_ENABLED is set by rt2x00queue_update_beacon() and cleared by
rt2x00queue_clear_beacon(). The number of entries with bit
ENTRY_BCN_ENABLED set will be test against intf_beaconing. If they do
not match, WARN_ON_ONCE will be triggered. So I think race condition
can occur with that if() clause, that's why it is removed altogether
in this patch.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel