I suggested a patch for loading modules from interruptible mode, but this patch remained unclaimed ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124851.html ).
For some reason I thought that this patch had been removed and did not track the fate of this code ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124573.html ).
On 1/1/19 5: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/0x00000100
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.