All of lore.kernel.org
 help / color / mirror / Atom feed
* kernel BUG in new r8188eu
@ 2021-07-30 19:59 Larry Finger
  2021-07-31  5:37 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 13+ messages in thread
From: Larry Finger @ 2021-07-30 19:59 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: LKML, linux-staging

Greg,

When I unplug the USB device with the driver loaded, I get the following BUG and 
my laptop freezes:

kernel: BUG: unable to handle page fault for address: ffffeb0200043248
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x0000) - not-present page

The traceback points to a kfree() call. I do not understand this BUG. Can you 
explain what happens?

I think I know how to avoid the BUG, but that might be at the expense of a 
memory leak.

Thanks,

Larry

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-07-30 19:59 kernel BUG in new r8188eu Larry Finger
@ 2021-07-31  5:37 ` Greg Kroah-Hartman
  2021-07-31 16:18   ` Larry Finger
  0 siblings, 1 reply; 13+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-31  5:37 UTC (permalink / raw)
  To: Larry Finger; +Cc: LKML, linux-staging

On Fri, Jul 30, 2021 at 02:59:44PM -0500, Larry Finger wrote:
> Greg,
> 
> When I unplug the USB device with the driver loaded, I get the following BUG
> and my laptop freezes:
> 
> kernel: BUG: unable to handle page fault for address: ffffeb0200043248
> kernel: #PF: supervisor read access in kernel mode
> kernel: #PF: error_code(0x0000) - not-present page
> 
> The traceback points to a kfree() call. I do not understand this BUG. Can
> you explain what happens?

Is this a new regression due to the recent cleanups, or something that
has always been here?

As for the error, looks like someone is reading to an address that is
in userspace without doing the proper copy_from_user() thing.  Do you
have a full traceback?

> I think I know how to avoid the BUG, but that might be at the expense of a
> memory leak.

That shouldn't be needed :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-07-31  5:37 ` Greg Kroah-Hartman
@ 2021-07-31 16:18   ` Larry Finger
  2021-07-31 18:53     ` Fabio Aiuto
  2021-08-01  6:31     ` Greg Kroah-Hartman
  0 siblings, 2 replies; 13+ messages in thread
From: Larry Finger @ 2021-07-31 16:18 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: LKML, linux-staging

On 7/31/21 12:37 AM, Greg Kroah-Hartman wrote:
> Is this a new regression due to the recent cleanups, or something that
> has always been here?

I suspect that it has been there forever. I was just doing the kinds of things a 
user might do, and locked up my box.

> As for the error, looks like someone is reading to an address that is
> in userspace without doing the proper copy_from_user() thing.  Do you
> have a full traceback?

  BUG: unable to handle page fault for address: ffffeb020003b848
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G         C O 
5.14.0-rc2-00157-g390c661543a8 #8
  Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50   09/29/2014
  Workqueue: usb_hub_wq hub_event [usbcore]
  RIP: 0010:kfree+0x68/0x2c0
  Code: 01 e5 0f 82 5f 02 00 00 48 b8 00 00 00 80 7f 77 00 00 48 01 c5 48 b8 00 
00 00 00 00 ea ff ff 48 c1 ed 0c 48 c1 e5 06 48 01 c5 <48> 8b 45 0>
  RSP: 0018:ffffc900001efa78 EFLAGS: 00010282
  RAX: ffffea0000000000 RBX: ffffc90000ee1028 RCX: 000000008010000d
  RDX: 0000000000000000 RSI: ffffffffa149eddf RDI: ffffc90000ee1578
  RBP: ffffeb020003b840 R08: 0000000000000001 R09: 0000000000000001
  R10: 0000000000000000 R11: ffff888121c0e400 R12: ffffc90000ee1578
  R13: ffff888101fd0000 R14: ffff888101fd0030 R15: 0000000000000003
  FS:  0000000000000000(0000) GS:ffff888323280000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: ffffeb020003b848 CR3: 000000000220a002 CR4: 00000000001706e0
  Call Trace:
   ? kfree+0x25a/0x2c0
   rtw_free_mlme_priv_ie_data+0x15/0xf8 [r8188eu]
   _rtw_free_mlme_priv+0xe/0x30 [r8188eu]
   rtw_free_mlme_priv+0x1a/0x47 [r8188eu]
   rtw_free_drv_sw+0x5c/0x1ae [r8188eu]
   rtw_usb_if1_deinit+0x67/0xcd [r8188eu]
   rtw_dev_remove+0x5a/0xf4 [r8188eu]
   usb_unbind_interface+0x8a/0x270 [usbcore]
   ? kernfs_find_ns+0x35/0xd0
   __device_release_driver+0x1a0/0x260
   device_release_driver+0x24/0x30
   bus_remove_device+0xd8/0x140
   device_del+0x18b/0x3e0
   ? kobject_cleanup+0x49/0x130
   usb_disable_device+0xd9/0x260 [usbcore]
   usb_disconnect.cold+0x7b/0x201 [usbcore]
   hub_port_connect+0x88/0x8d0 [usbcore]
   ? kfree+0xe6/0x2c0
   hub_port_connect_change+0xb1/0x3a0 [usbcore]
   port_event+0x5d4/0x720 [usbcore]
   hub_event+0x1db/0x430 [usbcore]
   process_one_work+0x1dd/0x3a0
   worker_thread+0x50/0x3f0
   ? rescuer_thread+0x390/0x390
   kthread+0x128/0x140
   ? set_kthread_struct+0x40/0x40
   ret_from_fork+0x22/0x30
  Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ctr ccm 
r8188eu(C) rfcomm rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs>
   crypto_simd cryptd i915 i2c_algo_bit serio_raw ttm drm_kms_helper syscopyarea 
sysfillrect sysimgblt fb_sys_fops drm xhci_pci ehci_pci xhci_hcd >
  CR2: ffffeb020003b848
  ---[ end trace f5f4e2b2680b5fd7 ]---

The driver is allocating some buffers using kmalloc variants, and others using 
vmalloc. I checked to see if there was confusion on which form of free should be 
used, but this one is allocated with kmalloc and freed with kfree, which should 
be OK.

Larry

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-07-31 16:18   ` Larry Finger
@ 2021-07-31 18:53     ` Fabio Aiuto
  2021-07-31 21:54       ` Larry Finger
  2021-08-01  6:31     ` Greg Kroah-Hartman
  1 sibling, 1 reply; 13+ messages in thread
From: Fabio Aiuto @ 2021-07-31 18:53 UTC (permalink / raw)
  To: Larry Finger; +Cc: Greg Kroah-Hartman, LKML, linux-staging

Hi all,

On Sat, Jul 31, 2021 at 11:18:10AM -0500, Larry Finger wrote:
> On 7/31/21 12:37 AM, Greg Kroah-Hartman wrote:
> > Is this a new regression due to the recent cleanups, or something that
> > has always been here?
> 
> I suspect that it has been there forever. I was just doing the kinds of
> things a user might do, and locked up my box.
> 
> > As for the error, looks like someone is reading to an address that is
> > in userspace without doing the proper copy_from_user() thing.  Do you
> > have a full traceback?
> 
>  BUG: unable to handle page fault for address: ffffeb020003b848
>  #PF: supervisor read access in kernel mode
>  #PF: error_code(0x0000) - not-present page
>  PGD 0 P4D 0
>  Oops: 0000 [#1] SMP PTI
>  CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G         C O
> 5.14.0-rc2-00157-g390c661543a8 #8
>  Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50   09/29/2014
>  Workqueue: usb_hub_wq hub_event [usbcore]
>  RIP: 0010:kfree+0x68/0x2c0
>  Code: 01 e5 0f 82 5f 02 00 00 48 b8 00 00 00 80 7f 77 00 00 48 01 c5 48 b8
> 00 00 00 00 00 ea ff ff 48 c1 ed 0c 48 c1 e5 06 48 01 c5 <48> 8b 45 0>
>  RSP: 0018:ffffc900001efa78 EFLAGS: 00010282
>  RAX: ffffea0000000000 RBX: ffffc90000ee1028 RCX: 000000008010000d
>  RDX: 0000000000000000 RSI: ffffffffa149eddf RDI: ffffc90000ee1578
>  RBP: ffffeb020003b840 R08: 0000000000000001 R09: 0000000000000001
>  R10: 0000000000000000 R11: ffff888121c0e400 R12: ffffc90000ee1578
>  R13: ffff888101fd0000 R14: ffff888101fd0030 R15: 0000000000000003
>  FS:  0000000000000000(0000) GS:ffff888323280000(0000) knlGS:0000000000000000
>  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>  CR2: ffffeb020003b848 CR3: 000000000220a002 CR4: 00000000001706e0
>  Call Trace:
>   ? kfree+0x25a/0x2c0
>   rtw_free_mlme_priv_ie_data+0x15/0xf8 [r8188eu]
>   _rtw_free_mlme_priv+0xe/0x30 [r8188eu]
>   rtw_free_mlme_priv+0x1a/0x47 [r8188eu]
>   rtw_free_drv_sw+0x5c/0x1ae [r8188eu]
>   rtw_usb_if1_deinit+0x67/0xcd [r8188eu]
>   rtw_dev_remove+0x5a/0xf4 [r8188eu]
>   usb_unbind_interface+0x8a/0x270 [usbcore]
>   ? kernfs_find_ns+0x35/0xd0
>   __device_release_driver+0x1a0/0x260
>   device_release_driver+0x24/0x30
>   bus_remove_device+0xd8/0x140
>   device_del+0x18b/0x3e0
>   ? kobject_cleanup+0x49/0x130
>   usb_disable_device+0xd9/0x260 [usbcore]
>   usb_disconnect.cold+0x7b/0x201 [usbcore]
>   hub_port_connect+0x88/0x8d0 [usbcore]
>   ? kfree+0xe6/0x2c0
>   hub_port_connect_change+0xb1/0x3a0 [usbcore]
>   port_event+0x5d4/0x720 [usbcore]
>   hub_event+0x1db/0x430 [usbcore]
>   process_one_work+0x1dd/0x3a0
>   worker_thread+0x50/0x3f0
>   ? rescuer_thread+0x390/0x390
>   kthread+0x128/0x140
>   ? set_kthread_struct+0x40/0x40
>   ret_from_fork+0x22/0x30
>  Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ctr ccm
> r8188eu(C) rfcomm rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs>
>   crypto_simd cryptd i915 i2c_algo_bit serio_raw ttm drm_kms_helper
> syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_pci ehci_pci xhci_hcd
> >
>  CR2: ffffeb020003b848
>  ---[ end trace f5f4e2b2680b5fd7 ]---
> 
> The driver is allocating some buffers using kmalloc variants, and others
> using vmalloc. I checked to see if there was confusion on which form of free
> should be used, but this one is allocated with kmalloc and freed with kfree,
> which should be OK.
> 
> Larry
> 

Maybe hostapd is involved. Try killing hostapd before and then
unplug the dongle... does the system freeze?

#include "../include/rtw_android.h"
int rtw_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
        struct iwreq *wrq = (struct iwreq *)rq;
        int ret = 0;

        switch (cmd) {
        case RTL_IOCTL_WPA_SUPPLICANT:
                ret = wpa_supplicant_ioctl(dev, &wrq->u.data);
                break;
#ifdef CONFIG_88EU_AP_MODE
        case RTL_IOCTL_HOSTAPD:
                ret = rtw_hostapd_ioctl(dev, &wrq->u.data);
        	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think that someone tries to write the wrong fields while
freeing memory...        

	break;
#endif /*  CONFIG_88EU_AP_MODE */
        case SIOCDEVPRIVATE:

static int rtw_hostapd_ioctl(struct net_device *dev, struct iw_point *p)
{
        struct ieee_param *param;
        int ret = 0;
        struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);

...

        switch (param->cmd) {
        case RTL871X_HOSTAPD_FLUSH:
                ret = rtw_hostapd_sta_flush(dev);
                break;
...
        case RTL871X_HOSTAPD_SET_WPS_BEACON:
                ret = rtw_set_wps_beacon(dev, param, p->length);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		break;

static int rtw_set_wps_beacon(struct net_device *dev, struct ieee_param *param, int len)
{
        int ret = 0;
       
...

                memcpy(pmlmepriv->wps_beacon_ie, param->u.bcn_ie.buf, ie_len);
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		maybe hotsapd does some ioctl at the wrong moment. 

Just to verify, we could kill hostapd, if ever runs in your machine...

thank you,

fabio

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-07-31 18:53     ` Fabio Aiuto
@ 2021-07-31 21:54       ` Larry Finger
  0 siblings, 0 replies; 13+ messages in thread
From: Larry Finger @ 2021-07-31 21:54 UTC (permalink / raw)
  To: Fabio Aiuto; +Cc: Greg Kroah-Hartman, LKML, linux-staging

On 7/31/21 1:53 PM, Fabio Aiuto wrote:
> Hi all,
> 
> On Sat, Jul 31, 2021 at 11:18:10AM -0500, Larry Finger wrote:
>> On 7/31/21 12:37 AM, Greg Kroah-Hartman wrote:
>>> Is this a new regression due to the recent cleanups, or something that
>>> has always been here?
>>
>> I suspect that it has been there forever. I was just doing the kinds of
>> things a user might do, and locked up my box.
>>
>>> As for the error, looks like someone is reading to an address that is
>>> in userspace without doing the proper copy_from_user() thing.  Do you
>>> have a full traceback?
>>
>>   BUG: unable to handle page fault for address: ffffeb020003b848
>>   #PF: supervisor read access in kernel mode
>>   #PF: error_code(0x0000) - not-present page
>>   PGD 0 P4D 0
>>   Oops: 0000 [#1] SMP PTI
>>   CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G         C O
>> 5.14.0-rc2-00157-g390c661543a8 #8
>>   Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50   09/29/2014
>>   Workqueue: usb_hub_wq hub_event [usbcore]
>>   RIP: 0010:kfree+0x68/0x2c0
>>   Code: 01 e5 0f 82 5f 02 00 00 48 b8 00 00 00 80 7f 77 00 00 48 01 c5 48 b8
>> 00 00 00 00 00 ea ff ff 48 c1 ed 0c 48 c1 e5 06 48 01 c5 <48> 8b 45 0>
>>   RSP: 0018:ffffc900001efa78 EFLAGS: 00010282
>>   RAX: ffffea0000000000 RBX: ffffc90000ee1028 RCX: 000000008010000d
>>   RDX: 0000000000000000 RSI: ffffffffa149eddf RDI: ffffc90000ee1578
>>   RBP: ffffeb020003b840 R08: 0000000000000001 R09: 0000000000000001
>>   R10: 0000000000000000 R11: ffff888121c0e400 R12: ffffc90000ee1578
>>   R13: ffff888101fd0000 R14: ffff888101fd0030 R15: 0000000000000003
>>   FS:  0000000000000000(0000) GS:ffff888323280000(0000) knlGS:0000000000000000
>>   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>   CR2: ffffeb020003b848 CR3: 000000000220a002 CR4: 00000000001706e0
>>   Call Trace:
>>    ? kfree+0x25a/0x2c0
>>    rtw_free_mlme_priv_ie_data+0x15/0xf8 [r8188eu]
>>    _rtw_free_mlme_priv+0xe/0x30 [r8188eu]
>>    rtw_free_mlme_priv+0x1a/0x47 [r8188eu]
>>    rtw_free_drv_sw+0x5c/0x1ae [r8188eu]
>>    rtw_usb_if1_deinit+0x67/0xcd [r8188eu]
>>    rtw_dev_remove+0x5a/0xf4 [r8188eu]
>>    usb_unbind_interface+0x8a/0x270 [usbcore]
>>    ? kernfs_find_ns+0x35/0xd0
>>    __device_release_driver+0x1a0/0x260
>>    device_release_driver+0x24/0x30
>>    bus_remove_device+0xd8/0x140
>>    device_del+0x18b/0x3e0
>>    ? kobject_cleanup+0x49/0x130
>>    usb_disable_device+0xd9/0x260 [usbcore]
>>    usb_disconnect.cold+0x7b/0x201 [usbcore]
>>    hub_port_connect+0x88/0x8d0 [usbcore]
>>    ? kfree+0xe6/0x2c0
>>    hub_port_connect_change+0xb1/0x3a0 [usbcore]
>>    port_event+0x5d4/0x720 [usbcore]
>>    hub_event+0x1db/0x430 [usbcore]
>>    process_one_work+0x1dd/0x3a0
>>    worker_thread+0x50/0x3f0
>>    ? rescuer_thread+0x390/0x390
>>    kthread+0x128/0x140
>>    ? set_kthread_struct+0x40/0x40
>>    ret_from_fork+0x22/0x30
>>   Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ctr ccm
>> r8188eu(C) rfcomm rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs>
>>    crypto_simd cryptd i915 i2c_algo_bit serio_raw ttm drm_kms_helper
>> syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_pci ehci_pci xhci_hcd
>>>
>>   CR2: ffffeb020003b848
>>   ---[ end trace f5f4e2b2680b5fd7 ]---
>>
>> The driver is allocating some buffers using kmalloc variants, and others
>> using vmalloc. I checked to see if there was confusion on which form of free
>> should be used, but this one is allocated with kmalloc and freed with kfree,
>> which should be OK.
>>
>> Larry
>>
> 
> Maybe hostapd is involved. Try killing hostapd before and then
> unplug the dongle... does the system freeze?
> 
> #include "../include/rtw_android.h"
> int rtw_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> {
>          struct iwreq *wrq = (struct iwreq *)rq;
>          int ret = 0;
> 
>          switch (cmd) {
>          case RTL_IOCTL_WPA_SUPPLICANT:
>                  ret = wpa_supplicant_ioctl(dev, &wrq->u.data);
>                  break;
> #ifdef CONFIG_88EU_AP_MODE
>          case RTL_IOCTL_HOSTAPD:
>                  ret = rtw_hostapd_ioctl(dev, &wrq->u.data);
>          	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I think that someone tries to write the wrong fields while
> freeing memory...
> 
> 	break;
> #endif /*  CONFIG_88EU_AP_MODE */
>          case SIOCDEVPRIVATE:
> 
> static int rtw_hostapd_ioctl(struct net_device *dev, struct iw_point *p)
> {
>          struct ieee_param *param;
>          int ret = 0;
>          struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
> 
> ...
> 
>          switch (param->cmd) {
>          case RTL871X_HOSTAPD_FLUSH:
>                  ret = rtw_hostapd_sta_flush(dev);
>                  break;
> ...
>          case RTL871X_HOSTAPD_SET_WPS_BEACON:
>                  ret = rtw_set_wps_beacon(dev, param, p->length);
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 		break;
> 
> static int rtw_set_wps_beacon(struct net_device *dev, struct ieee_param *param, int len)
> {
>          int ret = 0;
>         
> ...
> 
>                  memcpy(pmlmepriv->wps_beacon_ie, param->u.bcn_ie.buf, ie_len);
> 		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 		maybe hotsapd does some ioctl at the wrong moment.
> 
> Just to verify, we could kill hostapd, if ever runs in your machine...

No, hostapd was not involved. I was using r8188eu in STA mode.

Larry


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-07-31 16:18   ` Larry Finger
  2021-07-31 18:53     ` Fabio Aiuto
@ 2021-08-01  6:31     ` Greg Kroah-Hartman
  2021-08-01 20:15       ` Larry Finger
  1 sibling, 1 reply; 13+ messages in thread
From: Greg Kroah-Hartman @ 2021-08-01  6:31 UTC (permalink / raw)
  To: Larry Finger; +Cc: LKML, linux-staging

On Sat, Jul 31, 2021 at 11:18:10AM -0500, Larry Finger wrote:
> On 7/31/21 12:37 AM, Greg Kroah-Hartman wrote:
> > Is this a new regression due to the recent cleanups, or something that
> > has always been here?
> 
> I suspect that it has been there forever. I was just doing the kinds of
> things a user might do, and locked up my box.
> 
> > As for the error, looks like someone is reading to an address that is
> > in userspace without doing the proper copy_from_user() thing.  Do you
> > have a full traceback?
> 
>  BUG: unable to handle page fault for address: ffffeb020003b848
>  #PF: supervisor read access in kernel mode
>  #PF: error_code(0x0000) - not-present page
>  PGD 0 P4D 0
>  Oops: 0000 [#1] SMP PTI
>  CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G         C O
> 5.14.0-rc2-00157-g390c661543a8 #8
>  Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50   09/29/2014
>  Workqueue: usb_hub_wq hub_event [usbcore]
>  RIP: 0010:kfree+0x68/0x2c0
>  Code: 01 e5 0f 82 5f 02 00 00 48 b8 00 00 00 80 7f 77 00 00 48 01 c5 48 b8
> 00 00 00 00 00 ea ff ff 48 c1 ed 0c 48 c1 e5 06 48 01 c5 <48> 8b 45 0>
>  RSP: 0018:ffffc900001efa78 EFLAGS: 00010282
>  RAX: ffffea0000000000 RBX: ffffc90000ee1028 RCX: 000000008010000d
>  RDX: 0000000000000000 RSI: ffffffffa149eddf RDI: ffffc90000ee1578
>  RBP: ffffeb020003b840 R08: 0000000000000001 R09: 0000000000000001
>  R10: 0000000000000000 R11: ffff888121c0e400 R12: ffffc90000ee1578
>  R13: ffff888101fd0000 R14: ffff888101fd0030 R15: 0000000000000003
>  FS:  0000000000000000(0000) GS:ffff888323280000(0000) knlGS:0000000000000000
>  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>  CR2: ffffeb020003b848 CR3: 000000000220a002 CR4: 00000000001706e0
>  Call Trace:
>   ? kfree+0x25a/0x2c0
>   rtw_free_mlme_priv_ie_data+0x15/0xf8 [r8188eu]
>   _rtw_free_mlme_priv+0xe/0x30 [r8188eu]
>   rtw_free_mlme_priv+0x1a/0x47 [r8188eu]
>   rtw_free_drv_sw+0x5c/0x1ae [r8188eu]
>   rtw_usb_if1_deinit+0x67/0xcd [r8188eu]
>   rtw_dev_remove+0x5a/0xf4 [r8188eu]
>   usb_unbind_interface+0x8a/0x270 [usbcore]
>   ? kernfs_find_ns+0x35/0xd0
>   __device_release_driver+0x1a0/0x260
>   device_release_driver+0x24/0x30
>   bus_remove_device+0xd8/0x140
>   device_del+0x18b/0x3e0
>   ? kobject_cleanup+0x49/0x130
>   usb_disable_device+0xd9/0x260 [usbcore]
>   usb_disconnect.cold+0x7b/0x201 [usbcore]
>   hub_port_connect+0x88/0x8d0 [usbcore]
>   ? kfree+0xe6/0x2c0
>   hub_port_connect_change+0xb1/0x3a0 [usbcore]
>   port_event+0x5d4/0x720 [usbcore]
>   hub_event+0x1db/0x430 [usbcore]
>   process_one_work+0x1dd/0x3a0
>   worker_thread+0x50/0x3f0
>   ? rescuer_thread+0x390/0x390
>   kthread+0x128/0x140
>   ? set_kthread_struct+0x40/0x40
>   ret_from_fork+0x22/0x30
>  Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ctr ccm
> r8188eu(C) rfcomm rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs>
>   crypto_simd cryptd i915 i2c_algo_bit serio_raw ttm drm_kms_helper
> syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_pci ehci_pci xhci_hcd
> >
>  CR2: ffffeb020003b848
>  ---[ end trace f5f4e2b2680b5fd7 ]---

Hm, if you revert c7e88ecbe328 ("staging: r8188eu: remove rtw_buf_free()
function"), does the crash go away?

> The driver is allocating some buffers using kmalloc variants, and others
> using vmalloc. I checked to see if there was confusion on which form of free
> should be used, but this one is allocated with kmalloc and freed with kfree,
> which should be OK.

I am worried that my "remove the wrapper" logic got something wrong
here, so if you could test the revert of that, I would appreciate it.

I think I need to go buy one of these devices so I can test cleanups
locally...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-01  6:31     ` Greg Kroah-Hartman
@ 2021-08-01 20:15       ` Larry Finger
  2021-08-02 10:36         ` Greg Kroah-Hartman
  0 siblings, 1 reply; 13+ messages in thread
From: Larry Finger @ 2021-08-01 20:15 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: LKML, linux-staging

On 8/1/21 1:31 AM, Greg Kroah-Hartman wrote:
> 
> I am worried that my "remove the wrapper" logic got something wrong
> here, so if you could test the revert of that, I would appreciate it.
> 
> I think I need to go buy one of these devices so I can test cleanups
> locally...

The bad commit was 9ff1cc4ef80e ("staging: r8188eu: remove rtw_buf_free() 
function").

Looking at it, the only difference between the original wrapper and the new code 
is that the wrapper zeros the len variable before the kfree() call, but making 
that change did not help. Reverting that patch restores the old behavior.

There are lots of these on Ebay from $2.47 up with free shipping!

Larry


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-01 20:15       ` Larry Finger
@ 2021-08-02 10:36         ` Greg Kroah-Hartman
  2021-08-02 11:45           ` Fabio M. De Francesco
  2021-08-02 14:49           ` Larry Finger
  0 siblings, 2 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2021-08-02 10:36 UTC (permalink / raw)
  To: Larry Finger; +Cc: LKML, linux-staging

On Sun, Aug 01, 2021 at 03:15:52PM -0500, Larry Finger wrote:
> On 8/1/21 1:31 AM, Greg Kroah-Hartman wrote:
> > 
> > I am worried that my "remove the wrapper" logic got something wrong
> > here, so if you could test the revert of that, I would appreciate it.
> > 
> > I think I need to go buy one of these devices so I can test cleanups
> > locally...
> 
> The bad commit was 9ff1cc4ef80e ("staging: r8188eu: remove rtw_buf_free()
> function").
> 
> Looking at it, the only difference between the original wrapper and the new
> code is that the wrapper zeros the len variable before the kfree() call, but
> making that change did not help. Reverting that patch restores the old
> behavior.

Ah, doh, that was my fault, sorry, that patch was incorrect (odd git id,
don't know where that came from, it's a different id in my tree.)  Let
me revert this commit and then will redo it correctly.

thanks for finding this.

> There are lots of these on Ebay from $2.47 up with free shipping!

Any hints on the name for how to figure out which devices are supported
by this driver?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-02 10:36         ` Greg Kroah-Hartman
@ 2021-08-02 11:45           ` Fabio M. De Francesco
  2021-08-02 14:38             ` Greg Kroah-Hartman
  2021-08-02 14:40             ` Larry Finger
  2021-08-02 14:49           ` Larry Finger
  1 sibling, 2 replies; 13+ messages in thread
From: Fabio M. De Francesco @ 2021-08-02 11:45 UTC (permalink / raw)
  To: Larry Finger, Greg Kroah-Hartman; +Cc: LKML, linux-staging

Hi Greg,

On Monday, August 2, 2021 12:36:18 PM CEST Greg Kroah-Hartman wrote:
> On Sun, Aug 01, 2021 at 03:15:52PM -0500, Larry Finger wrote:
> > On 8/1/21 1:31 AM, Greg Kroah-Hartman wrote:
> > > I am worried that my "remove the wrapper" logic got something wrong
> > > here, so if you could test the revert of that, I would appreciate it.
> > > 
> > > I think I need to go buy one of these devices so I can test cleanups
> > > locally...
> > 
> > The bad commit was 9ff1cc4ef80e ("staging: r8188eu: remove rtw_buf_free()
> > function").
> > 
> > Looking at it, the only difference between the original wrapper and the 
new
> > code is that the wrapper zeros the len variable before the kfree() call, 
but
> > making that change did not help. Reverting that patch restores the old
> > behavior.
> 
> Ah, doh, that was my fault, sorry, that patch was incorrect (odd git id,
> don't know where that came from, it's a different id in my tree.)  Let
> me revert this commit and then will redo it correctly.

The commit to revert should be c7e88ecbe328.

> 
> thanks for finding this.
> 
> > There are lots of these on Ebay from $2.47 up with free shipping!
> 
> Any hints on the name for how to figure out which devices are supported
> by this driver?

The following link points to a device that seems to be supported by this 
driver. It is just $4.99, but I'm not sure whether or not they ship to Europe 
(I suppose you're here):

https://www.amazon.com/gp/product/B00L28AN88/ref=ox_sc_act_title_1
 
About this item: 
* Chipset:RTL8188EU 
* Standard: IEEE 802.11n,IEEE 802.11g, IEEE 802.11b 
* Supports 64/128 bit WEP, WPA encryption 

Otherwise, I think that the following uses the same chip as the above. 
However, it costs a little more and, above all else, I'm not really sure if it 
works with r8188eu, since they write that the chip is a Realtek RTL8188EUS 
(please note that final "EUS"):

https://www.amazon.it/Asus-USB-N10-NANO-N150-compatibile/dp/B081758CWC/
ref=sr_1_1

Thanks,

Fabio


> thanks,
> 
> greg k-h





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-02 11:45           ` Fabio M. De Francesco
@ 2021-08-02 14:38             ` Greg Kroah-Hartman
  2021-08-02 14:40             ` Larry Finger
  1 sibling, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2021-08-02 14:38 UTC (permalink / raw)
  To: Fabio M. De Francesco; +Cc: Larry Finger, LKML, linux-staging

On Mon, Aug 02, 2021 at 01:45:06PM +0200, Fabio M. De Francesco wrote:
> Hi Greg,
> 
> On Monday, August 2, 2021 12:36:18 PM CEST Greg Kroah-Hartman wrote:
> > On Sun, Aug 01, 2021 at 03:15:52PM -0500, Larry Finger wrote:
> > > On 8/1/21 1:31 AM, Greg Kroah-Hartman wrote:
> > > > I am worried that my "remove the wrapper" logic got something wrong
> > > > here, so if you could test the revert of that, I would appreciate it.
> > > > 
> > > > I think I need to go buy one of these devices so I can test cleanups
> > > > locally...
> > > 
> > > The bad commit was 9ff1cc4ef80e ("staging: r8188eu: remove rtw_buf_free()
> > > function").
> > > 
> > > Looking at it, the only difference between the original wrapper and the 
> new
> > > code is that the wrapper zeros the len variable before the kfree() call, 
> but
> > > making that change did not help. Reverting that patch restores the old
> > > behavior.
> > 
> > Ah, doh, that was my fault, sorry, that patch was incorrect (odd git id,
> > don't know where that came from, it's a different id in my tree.)  Let
> > me revert this commit and then will redo it correctly.
> 
> The commit to revert should be c7e88ecbe328.

Yes, thanks, now reverted.

> > thanks for finding this.
> > 
> > > There are lots of these on Ebay from $2.47 up with free shipping!
> > 
> > Any hints on the name for how to figure out which devices are supported
> > by this driver?
> 
> The following link points to a device that seems to be supported by this 
> driver. It is just $4.99, but I'm not sure whether or not they ship to Europe 
> (I suppose you're here):
> 
> https://www.amazon.com/gp/product/B00L28AN88/ref=ox_sc_act_title_1

Yeah, I'm in Europe, I'll try to find something within the EU to avoid
the mess with importing electronics and duties.  It's a mess everytime I
do that...

> About this item: 
> * Chipset:RTL8188EU 
> * Standard: IEEE 802.11n,IEEE 802.11g, IEEE 802.11b 
> * Supports 64/128 bit WEP, WPA encryption 
> 
> Otherwise, I think that the following uses the same chip as the above. 
> However, it costs a little more and, above all else, I'm not really sure if it 
> works with r8188eu, since they write that the chip is a Realtek RTL8188EUS 
> (please note that final "EUS"):
> 
> https://www.amazon.it/Asus-USB-N10-NANO-N150-compatibile/dp/B081758CWC/
> ref=sr_1_1

Yeah, I found a bunch of "EUS" devices here, will keep digging.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-02 11:45           ` Fabio M. De Francesco
  2021-08-02 14:38             ` Greg Kroah-Hartman
@ 2021-08-02 14:40             ` Larry Finger
  2021-08-02 15:46               ` Greg Kroah-Hartman
  1 sibling, 1 reply; 13+ messages in thread
From: Larry Finger @ 2021-08-02 14:40 UTC (permalink / raw)
  To: Fabio M. De Francesco, Greg Kroah-Hartman; +Cc: LKML, linux-staging

On 8/2/21 6:45 AM, Fabio M. De Francesco wrote:
> The following link points to a device that seems to be supported by this
> driver. It is just $4.99, but I'm not sure whether or not they ship to Europe
> (I suppose you're here):
> 
> https://www.amazon.com/gp/product/B00L28AN88/ref=ox_sc_act_title_1
>   
> About this item:
> * Chipset:RTL8188EU
> * Standard: IEEE 802.11n,IEEE 802.11g, IEEE 802.11b
> * Supports 64/128 bit WEP, WPA encryption
> 
> Otherwise, I think that the following uses the same chip as the above.
> However, it costs a little more and, above all else, I'm not really sure if it
> works with r8188eu, since they write that the chip is a Realtek RTL8188EUS
> (please note that final "EUS"):

The RTL8188EUS chips use the same driver as RTL8188EU. In fact, the one I am 
using is the EUS variety.

Larry


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-02 10:36         ` Greg Kroah-Hartman
  2021-08-02 11:45           ` Fabio M. De Francesco
@ 2021-08-02 14:49           ` Larry Finger
  1 sibling, 0 replies; 13+ messages in thread
From: Larry Finger @ 2021-08-02 14:49 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: LKML, linux-staging

On 8/2/21 5:36 AM, Greg Kroah-Hartman wrote:
> Ah, doh, that was my fault, sorry, that patch was incorrect (odd git id,
> don't know where that came from, it's a different id in my tree.)  Let
> me revert this commit and then will redo it correctly.
> 
> thanks for finding this.
> 
>> There are lots of these on Ebay from $2.47 up with free shipping!
> Any hints on the name for how to figure out which devices are supported
> by this driver?

I do not why my git id did not match yours.

It was no problem. After I determined that the original code was correct, it was 
an easy bisection - 6 cycles with only r8188eu needing rebuilding.

The driver supports RTL8188EU and RTL8188EUS. The name comes from the 8188E, and 
the U means a USB interface. The S indicates a new design that appears the same 
to the driver.

Larry


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: kernel BUG in new r8188eu
  2021-08-02 14:40             ` Larry Finger
@ 2021-08-02 15:46               ` Greg Kroah-Hartman
  0 siblings, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2021-08-02 15:46 UTC (permalink / raw)
  To: Larry Finger; +Cc: Fabio M. De Francesco, LKML, linux-staging

On Mon, Aug 02, 2021 at 09:40:42AM -0500, Larry Finger wrote:
> On 8/2/21 6:45 AM, Fabio M. De Francesco wrote:
> > The following link points to a device that seems to be supported by this
> > driver. It is just $4.99, but I'm not sure whether or not they ship to Europe
> > (I suppose you're here):
> > 
> > https://www.amazon.com/gp/product/B00L28AN88/ref=ox_sc_act_title_1
> > About this item:
> > * Chipset:RTL8188EU
> > * Standard: IEEE 802.11n,IEEE 802.11g, IEEE 802.11b
> > * Supports 64/128 bit WEP, WPA encryption
> > 
> > Otherwise, I think that the following uses the same chip as the above.
> > However, it costs a little more and, above all else, I'm not really sure if it
> > works with r8188eu, since they write that the chip is a Realtek RTL8188EUS
> > (please note that final "EUS"):
> 
> The RTL8188EUS chips use the same driver as RTL8188EU. In fact, the one I am
> using is the EUS variety.

Ah, nice to know, I've ordered this thing from my local supplier:
	https://www.megekko.nl/product/2113/992461/USB-Wi-Fi-sticks/StarTech-com-USB-150-Mbps-Mini-draadloze-netwerkadapter-802-11n-g-1T1R-USB-Wi-Fi-adapter-wit

so I can test and not do stupid things like that commit...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-08-02 18:32 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-30 19:59 kernel BUG in new r8188eu Larry Finger
2021-07-31  5:37 ` Greg Kroah-Hartman
2021-07-31 16:18   ` Larry Finger
2021-07-31 18:53     ` Fabio Aiuto
2021-07-31 21:54       ` Larry Finger
2021-08-01  6:31     ` Greg Kroah-Hartman
2021-08-01 20:15       ` Larry Finger
2021-08-02 10:36         ` Greg Kroah-Hartman
2021-08-02 11:45           ` Fabio M. De Francesco
2021-08-02 14:38             ` Greg Kroah-Hartman
2021-08-02 14:40             ` Larry Finger
2021-08-02 15:46               ` Greg Kroah-Hartman
2021-08-02 14:49           ` Larry Finger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.