Re: [GIT PULL] USB fixes for 5.9-rc3

[Greg KH]

On Wed, Aug 26, 2020 at 05:02:38PM +0200, Marek Szyprowski wrote:
> Hi Greg,
> 
> On 26.08.2020 15:43, Greg KH wrote:
> > The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
> >
> >    Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
> >
> > are available in the Git repository at:
> >
> >    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.9-rc3
> >
> > for you to fetch changes up to 23e26d0577535f5ffe4ff8ed6d06e009553c0bca:
> >
> >    usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA 2.3.1.2 failures (2020-08-25 16:02:35 +0200)
> >
> > ----------------------------------------------------------------
> > USB fixes for 5.9-rc3
> >
> > Here are a small set of USB fixes for 5.9-rc3.
> >
> > Like most set of USB bugfixes, they include the usual:
> > 	- usb gadget driver fixes
> > 	- xhci driver fixes
> > 	- typec fixes
> > 	- new qurks and ids
> > 	- fixes for USB patches merged in 5.9-rc1
> >
> > Nothing huge, all of these have been in linux-next with no reported
> > issues:
> >
> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> >
> > ----------------------------------------------------------------
> > Alan Stern (1):
> >        USB: yurex: Fix bad gfp argument
> >
> > Andy Shevchenko (1):
> >        usb: hcd: Fix use after free in usb_hcd_pci_remove()
> >
> > Badhri Jagan Sridharan (1):
> >        usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA 2.3.1.2 failures
> >
> > Bastien Nocera (2):
> >        USB: Also match device drivers using the ->match vfunc
> >        USB: Fix device driver race
> >
> > Brooke Basile (2):
> >        USB: gadget: u_f: add overflow checks to VLA macros
> 
> Sorry, but the above patch breaks USB Ethernet Gadget operation. It also 
> didn't get the proper testing in linux-next (next-20200826 is the first 
> one with this patch).
> 
> This is how it explodes on Samsung Exynos (ARM 32bit) based board with 
> g_ether module loaded:
> 
> ------------[ cut here ]------------
> kernel BUG at mm/slub.c:4116!

Why is slub.c erroring?  How is this related to freeing memory?

> Internal error: Oops - BUG: 0 [#1] SMP ARM
> Modules linked in: usb_f_ecm g_ether(+) usb_f_rndis u_ether libcomposite 
> panel_samsung_s6e8aa0 s5p_csis s5p_fimc exynos4_is_common v4l2_fwnode 
> max8997_regulator rtc_max8997 leds_max8997 max8
> emless mms114 governor_simpleondemand s5p_mfc lima gpu_sched s5p_jpeg 
> v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
> videobuf2_common phy_exynos_usb2 exynosdrm analogix_dp
>   s3c2410_wdt
> CPU: 0 PID: 616 Comm: modprobe Not tainted 5.9.0-rc1-00026-gb1cd1b65afba 
> #9023
> Hardware name: Samsung Exynos (Flattened Device Tree)
> PC is at kfree+0x234/0x268
> LR is at config_item_set_name+0x60/0xb0
> ...
> Process modprobe (pid: 616, stack limit = 0x(ptrval))
> ...
> [<c0494248>] (kfree) from [<c05347a0>] (config_item_set_name+0x60/0xb0)
> [<c05347a0>] (config_item_set_name) from [<c0534844>] 
> (config_group_init_type_name+0x1c/0x50)

Odd, for a "normal" descriptor, the logic should have remained the same
as without this patch.

What does the descriptor definition of your device look like that it
triggers this traceback?

> [<c0534844>] (config_group_init_type_name) from [<bf14bc18>] 
> (usb_os_desc_prepare_interf_dir+0x54/0x124 [libcomposite])
> [<bf14bc18>] (usb_os_desc_prepare_interf_dir [libcomposite]) from 
> [<bf15af9c>] (rndis_alloc_inst+0x100/0x150 [usb_f_rndis])
> [<bf15af9c>] (rndis_alloc_inst [usb_f_rndis]) from [<bf1499dc>] 
> (try_get_usb_function_instance+0x88/0xa4 [libcomposite])
> [<bf1499dc>] (try_get_usb_function_instance [libcomposite]) from 
> [<bf149ad8>] (usb_get_function_instance+0xc/0x44 [libcomposite])
> [<bf149ad8>] (usb_get_function_instance [libcomposite]) from 
> [<bf114164>] (eth_bind+0xdc/0x34c [g_ether])
> [<bf114164>] (eth_bind [g_ether]) from [<bf1497cc>] 
> (composite_bind+0x78/0x1a8 [libcomposite])
> [<bf1497cc>] (composite_bind [libcomposite]) from [<c0c62a0c>] 
> (udc_bind_to_driver+0x60/0x108)
> [<c0c62a0c>] (udc_bind_to_driver) from [<c0c62ed8>] 
> (usb_gadget_probe_driver+0x100/0x158)
> [<c0c62ed8>] (usb_gadget_probe_driver) from [<c0301fd0>] 
> (do_one_initcall+0x54/0x220)
> [<c0301fd0>] (do_one_initcall) from [<c03de390>] (do_init_module+0x60/0x210)
> [<c03de390>] (do_init_module) from [<c03dd0d4>] (load_module+0x2078/0x24c0)
> [<c03dd0d4>] (load_module) from [<c03dd758>] (sys_finit_module+0xc8/0xd8)
> [<c03dd758>] (sys_finit_module) from [<c03000c0>] 
> (ret_fast_syscall+0x0/0x54)
> Exception stack(0xedd1dfa8 to 0xedd1dff0)
> ...
> ---[ end trace 0dc21d79c1880545 ]---

Brooke, any ideas?

thanks,

greg k-h