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
