Nick Schaf <nick.sc...@jci.com> [2019-07-31 16:34:36]: Hi,
> I've noticed the wpa_supplicant process on my mesh interfaces leaking memory > to the point that the kernel kills the process. It was discovered in > 18.06.2, but I've reproduced it with 18.06.4 and with the master branch from > the GitHub repo. Since the leak occurs as mesh links are created and > destroyed, I was able to reproduce it with a simple two-node setup where I > monitor the wpa_supplicant process VSZ on one node and repeatedly bring wifi > up and down on the other node. > > I've traced it back to the 18.06.2 release, specifically to lines 34-35 of > package/network/services/hostapd/patches/015-mesh-do-not-use-offchan-mgmt-tx-on-DFS.patch > + (modes = nl80211_get_hw_feature_data(bss, &num_modes, > &flags, + > &dfs_domain)) && That code was added in > a35f24309021c1c0e9cbed0faedf58b941cb4bd3. > > I removed the entire patch file to resolve the memory leak because the > subsequent call to ieee80211_is_dfs() uses the return value from > nl80211_get_hw_feature_data(). However, I know the problem is specifically > related to the nl80211_get_hw_feature_data() call because I stepped-backward > through commits of the hostapd source until I got back to > 0f7fc6b98de9c69f511b9b22f2b65553126362eb, where ieee80211_is_dfs() had only > one argument and didn't rely on the nl80211_get_hw_feature_data() return > value. At that point, the memory leak still occurred until I commented-out > the call to nl80211_get_hw_feature_data(). > > I attempted to dive into nl80211_get_hw_feature_data(), but was quickly > lost, so I defer to those that are more experienced in that code. you did a nice job here to track it down, so thanks for reporting this, can you try this patch[1]? 1. https://git.openwrt.org/c818ab2b8649accb3739b9234f2d07e16011fda6 -- ynezz _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
