On 1/1/19 3:17 AM, Larry Finger wrote:
On 12/30/18 12:39 PM, Michael Straube wrote:Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt") is causing hardfreeze whenever the driver tries to connect to my wifi network. That makes the driver unusable on my system. Reverting the commit fixes the issue and the driver works properly. Dec 29 19:21:17 gentoo kernel: BUG: scheduling while atomic: swapper/6/0/0x00000100Michael, I have verified the freezes that you see. Although I have not been able to capture the console dump, I think we are likely seeing the same problem. I do have a work-around in that I have not gotten any freezes when I force module lib80211_crypt_ccmp to be loaded before I load module r8188eu. This clue was used in finding what seems to be a good fix. I do not know anything about demand loading of modules using try_then_request_module(); however, I noticed that the macro actually calls __request_module(), which has the following comment: * Load a module using the user mode module loader. The function returns * zero on success or a negative errno code or positive exit code from * "modprobe" on failure. Note that a successful module load does not mean * the module did not then unload and exit on an error of its own. Callers * must check that the service they requested is now available not blindly * invoke it. I note that it says "user mode module loader". Routine rtw_aes_decrypt() is likely inside some sort of locking, which leads to the "scheduling while atomic" bug that you see. As a result, I suspect that the module is not loaded, and that leads to the NULL dereference when the module is accessed. Please try the one-line patch attached, which forces lib80211 to load when r8188eu is loaded. With this patch, I have been connected to an AES-encrypted AP for nearly 3 hours with no problems. Larry
I've tested your patch and it solved the issue. No freezes and dmesg looks good. I noticed that try_then_request_module() is also used in rtw_wep_encrypt() and rtw_wep_decrypt(). I guess that also could cause problems? Michael _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
