Hi Daniel, > 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. Yes it is. Attached is a patch from Amitkumar Karwar to fix it. > > 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). One scan request from cfg80211 is split to multiple scan commands being sent from driver to firmware. If scan_request is cleared (e.g. mwifiex_close) during a scan command processing, all pending scan commands will be aborted after getting response of previous scan command, and scan_delay_timer is modified to fire in 50ms. With original script (mwifiex_sdio is removed), I don't see scan_delay_timer_fn() gets triggered either. My assumption is that the scan_pending_q has already been emptied, so we don't run into the same path as above. > > 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 With this new script (eth0 is down), I can easily see scan_delay_timer_fn() gets called. The scan_pending_q is not emptied in this case. > > 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). Sorry, it's my bad. I realized that my patch to cleanup user_scan_cfg in mwifiex_close() is wrong and it will cause this problem. Please wait for another patch that fixes the memory leak in mwifiex_cfg80211_scan. Thanks, Bing > > Thanks > Daniel
Attachment:
0001-mwifiex-fix-memory-leak-issue-when-driver-unload.patch
Description: 0001-mwifiex-fix-memory-leak-issue-when-driver-unload.patch
