On Wed, Apr 24, 2013 at 4:48 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: > However, strangely, it seems to make a whole bunch of kmemleak reports > *appear*, as if the struct netdev is not being destroyed, and more. I > guess this could just be a kmemleak oddity but it is strange that it > did not appear before this patch. While I don't have an explanation for why kmemleak didn't detect this before, I have confirmed with some simple printks that mwifiex does not call free_netdev on the netdev that it allocates, at least when using the test script posted earlier in this thread. So that is another leak that must be fixed. > Trying to look for possible causes (memory corruption?), I can't see > any code that serializes scan_delay_timer_fn with mwifiex_close(), so > mwifiex_close freeing the scan data while scan_delay_timer_fn is using > it could cause badness to happen. However I haven't yet figured out > how to trigger scan_delay_timer_fn to execute even once (any tips?). I still haven't figured out how to make this code trigger, but I looked again, and I do believe there is a potential crash waiting for us here, because there is no serialization between mwifiex_close and the possible running of this timer (which uses user_scan_cfg). Also, I found another issue. Change the script to: insmod mwifiex_sdio.ko sleep 1 ifconfig eth0 up iwlist eth0 scan & sleep 0.1 ifconfig eth0 down and add printk's in mwifiex_close (where user_scan_cfg is freed) and in mwifiex_cfg80211_scan() (where user_cfg_cfg is used and also freed). You can see that mwifiex_cfg80211_scan() executes at the same time as mwifiex_close() (and several times after) and I can't see any serialization here, so I think there are some other crashes here as well (e.g. looks like it could race and we could double-free user_scan_cfg). Thanks Daniel -- 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
