Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 1/2/19 4:06 AM, Larry Finger wrote: On 1/1/19 1:31 PM, Michael Straube wrote: 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? Yes, I believe it would if anyone is still using WEP. My plan is to get rid of the try_then_request_module() there as well, and for completeness, I plan to restore usage of the lib80211 routines for TKIP as well. Patch "load lib80211 crypto ops from interruptible context" ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124851.html ) is a preparation to replace crypto_ops = try_then_request_module(lib80211_get_crypto_ops(*), "lib80211_crypt_*"); with (struct crypto_algorithm).ops Once I get a chance to test the TKIP and WEP changes, I plan to have a set of 4 patches to switch the driver to using lib80211 routines for all decryption/encryption. There are four other patches to use lib80211: use lib80211 CCMP decrypt ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-February/116533.html ) Use lib80211 to encrypt (WEP) tx frames ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/122642.html ) Use lib80211 to encrypt (TKIP) tx frames ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-July/123249.html ) Use lib80211 to encrypt (CCMP) tx frames ( http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-July/123250.html ) They all crash when try_then_request_module() called. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 1/2/19 12:38 AM, Larry Finger wrote: On 1/1/19 3:02 AM, Ivan Safonov wrote: 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 ). That patch was quite extensive, but had only a minimal commit message. I'm surprised that it did not get a bad review, but I can see why it was ignored. > Where did you submit that patch? It certainly was never in my mailbox. I send patches to emails from get_maintainer.pl list: ivan@alpha ~/source/kernels/staging $ git format-patch 515ce733e86ee2e1bea4dba76d2d4491013d0f73^..515ce733e86ee2e1bea4dba76d2d4491013d0f73 -o /tmp/ /tmp/0001-staging-r8188eu-Use-lib80211-to-encrypt-CCMP-tx-fram.patch ivan@alpha ~/source/kernels/staging $ ./scripts/get_maintainer.pl /tmp/0001-staging-r8188eu-Use-lib80211-to-encrypt-CCMP-tx-fram.patch Greg Kroah-Hartman (supporter:STAGING SUBSYSTEM,commit_signer:16/16=100%,authored:1/16=6%,added_lines:345/1450=24%) Ivan Safonov (commit_signer:7/16=44%,authored:6/16=38%,added_lines:337/1450=23%,removed_lines:1380/1605=86%) Michael Straube (commit_signer:6/16=38%,authored:6/16=38%,added_lines:715/1450=49%,removed_lines:92/1605=6%) Santha Meena Ramamoorthy (commit_signer:2/16=12%,authored:2/16=12%) Dan Carpenter (commit_signer:1/16=6%) Hans de Goede (authored:1/16=6%) de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM) linux-ker...@vger.kernel.org (open list) There is no your email. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 1/1/19 1:31 PM, Michael Straube wrote: 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? Yes, I believe it would if anyone is still using WEP. My plan is to get rid of the try_then_request_module() there as well, and for completeness, I plan to restore usage of the lib80211 routines for TKIP as well. Once I get a chance to test the TKIP and WEP changes, I plan to have a set of 4 patches to switch the driver to using lib80211 routines for all decryption/encryption. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 1/1/19 3:02 AM, Ivan Safonov wrote: 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 ). That patch was quite extensive, but had only a minimal commit message. I'm surprised that it did not get a bad review, but I can see why it was ignored. Where did you submit that patch? It certainly was never in my mailbox. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 1/1/19 10:02 AM, Ivan Safonov wrote:
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
).
So with these changes try_then_request_module() would work properly?
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
).
I reverted that patch (there are conflicts meanwhile) and removed
try_then_request_module() in rtw_aes_encrypt() and it looks good.
Perhaps the same applies for the reverted TKIP changes?
Michael
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/0x0100
Michael,
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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
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/0x0100
Michael,
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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
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/0x0100
Michael,
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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
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/0x0100
Michael,
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
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index f7407632e80b..052656a22821 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1291,7 +1291,7 @@ u32 rtw_aes_decrypt(struct adapter *padapter, u8
*precvframe)
struct sk_buff *skb = ((struct recv_frame
*)precvframe)->pkt;
void *crypto_private = NULL;
u8 *key, *pframe = skb->data;
- struct lib80211_crypto_ops *crypto_ops =
try_then_request_module(lib80211_get_crypto_ops("CCMP"), "lib80211_crypt_ccmp");
+ struct lib80211_crypto_ops *crypto_ops =
lib80211_get_crypto_ops("CCMP");
struct security_priv *psecuritypriv =
&padapter->securitypriv;
char iv[8], icv[8];
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
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/0x0100
Dec 29 19:21:17 gentoo kernel: Modules linked in: vfat r8188eu(C) lib80211
cfg80211 rfkill snd_hda_codec_realtek amdgpu
snd_hda_codec_generic snd_hda_codec_hdmi mfd_core chash edac_mce_amd gpu_sched
snd_hda_intel ttm wmi_bmof kvm
drm_kms_helper snd_hda_codec irqbypass snd_hwdep crc32c_intel snd_hda_core drm
snd_pcm ghash_clmulni_intel snd_timer
syscopyarea cryptd snd sysfillrect pcspkr sysimgblt k10temp fb_sys_fops
soundcore wmi video xts cbc ixgb ixgbe tulip
cxgb3 cxgb mdio cxgb4 vxge bonding vxlan ip6_udp_tunnel udp_tunnel macvlan
vmxnet3 tg3 sky2 r8169 libphy pcnet32 mii igb
dca i2c_algo_bit i2c_core e1000 bnx2 atl1c msdos fat efivarfs configfs cramfs
squashfs fuse nfs lockd grace sunrpc
fscache ext4 jbd2 ext2 mbcache linear raid10 raid1 raid0 dm_zero dm_verity
reed_solomon dm_thin_pool dm_switch
dm_snapshot dm_raid raid456 async_raid6_recov async_memcpy async_pq raid6_pq
dm_mirror dm_region_hash dm_log_writes
dm_log_userspace dm_log dm_integrity async_xor xor async_tx dm_flakey dm_era
dm_delay dm_crypt
Dec 29 19:21:17 gentoo kernel: dm_cache_smq dm_cache dm_persistent_data
libcrc32c dm_bufio dm_bio_prison dm_mod
firewire_core crc_itu_t sl811_hcd xhci_pci xhci_hcd usb_storage mpt3sas
raid_class aic94xx libsas lpfc qla2xxx
megaraid_sas megaraid_mbox megaraid_mm aacraid sx8 hpsa 3w_9xxx 3w_ 3w_sas
mptsas scsi_transport_sas mptfc
scsi_transport_fc mptspi mptscsih mptbase imm parport sym53c8xx initio arcmsr
aic7xxx aic79xx scsi_transport_spi sr_mod
cdrom sg sd_mod pdc_adma sata_inic162x sata_mv ata_piix ahci libahci sata_qstor
sata_vsc sata_uli sata_sis sata_sx4
sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise pata_via
pata_jmicron pata_marvell pata_sis pata_netcell
pata_pdc202xx_old pata_atiixp pata_amd pata_ali pata_it8213 pata_pcmcia
pata_serverworks pata_oldpiix pata_artop
pata_it821x pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x
pata_sil680 pata_pdc2027x nvme nvme_core
virtio_net net_failover failover virtio_crypto crypto_engine virtio_mmio
virtio_pci virtio_balloon virtio_rng
Dec 29 19:21:17 gentoo kernel: virtio_console virtio_blk virtio_scsi
virtio_ring virtio
Dec 29 19:21:17 gentoo kernel: CPU: 6 PID: 0 Comm: swapper/6 Tainted: G
WC4.20.0-gentoo #1
Dec 29 19:21:17 gentoo kernel: Hardware name: Gigabyte Technology Co., Ltd.
A320M-S2H/A320M-S2H-CF, BIOS F23 08/08/2018
Dec 29 19:21:17 gentoo kernel: Call Trace:
Dec 29 19:21:17 gentoo kernel:
Dec 29 19:21:17 gentoo kernel: dump_stack+0x67/0x9b
Dec 29 19:21:17 gentoo kernel: __schedule_bug+0x4c/0x70
Dec 29 19:21:17 gentoo kernel: __schedule+0x6d7/0x840
Dec 29 19:21:17 gentoo kernel: ? enqueue_task_fair+0xa8/0x6d0
Dec 29 19:21:17 gentoo kernel: schedule+0x28/0x80
Dec 29 19:21:17 gentoo kernel: schedule_timeout+0x1f9/0x440
Dec 29 19:21:17 gentoo kernel: ? _raw_spin_unlock_irqrestore+0x21/0x30
Dec 29 19:21:17 gentoo kernel: ? wait_for_common+0xb5/0x180
Dec 29 19:21:17 gentoo kernel: wait_for_common+0xbe/0x180
Dec 29 19:21:17 gentoo kernel: ? wake_up_q+0x80/0x80
Dec 29 19:21:17 gentoo kernel: ? rtw_aes_decrypt+0x1b9/0x200 [r8188eu]
Dec 29 19:21:17 gentoo kernel: wait_for_completion_killable+0x19/0x30
Dec 29 19:21:17 gentoo kernel: call_usermodehelper_exec+0xeb/0x170
Dec 29 19:21:17 gentoo kernel: __request_module+0x1a1/0x430
Dec 29 19:21:17 gentoo kernel: ? fetch_pte.isra.1+0x5/0x180
Dec 29 19:21:17 gentoo kernel: ? iommu_unmap_page+0x6b/0x100
Dec 29 19:21:17 gentoo kernel: ? _raw_spin_unlock_irqrestore+0x16/0x30
Dec 29 19:21:17 gentoo kernel: rtw_aes_decrypt+0x1b9/0x200 [r8188eu]
Dec 29 19:21:17 gentoo kernel: recv_func_posthandle+0x346/0x960 [r8188eu]
Dec 29 19:21:17 gentoo kernel: rtw_recv_entry+0x48e/0x980 [r8188eu]
Dec 29 19:21:17 gentoo kernel: rtl8188eu_recv_tasklet+0xac/0x5b0 [r8188eu]
Dec 29 19:21:17 gentoo kernel: ? tasklet_action_common.isra.5+0x2e/0xb0
Dec 29 19:21:17 gentoo kernel: ? tasklet_action_common.isra.5+0x4c/0xb0
Dec 29 19:21:17 gentoo kernel: tasklet_action_common.isra.5+0x4c/0xb0
Dec 29 19:21:17 gentoo kernel: __do_softirq+0x104/0x365
Dec 29 19:21:17 gentoo kernel: irq_exit+0xd1/0xe0
Dec 29 19:21:17 gentoo kernel: do_IRQ+0x85/0xd0
Dec 29 19:21:17 gentoo kernel: common_interrupt+0xf/0xf
Dec 29 19:21:17 gentoo kernel:
Dec 29 19:21:17 gentoo kernel: RIP: 0010:cpuidle_enter_state+0xba/0x320
Dec 29 19:21:17 gentoo kernel: Code: 1f 44 00 00 31 ff e8 75 89 b3 ff 45 84 f6
74 12 9c 58 f6 c4 02 0f 85 3b 02 00 00 31
ff e8 9e dd b8 ff e8 e9 ad bd ff fb 85 ed <0f> 88 19 02 00 00 4c 29 fb 48 ba cf
f7 53 e3 a5 9b c4 20 48 89 d8
Dec 29 19:21:17 gentoo kernel: RSP: 0018:b6fd800c3ea0 EFLAGS: 0202
ORIG_RAX
