Re: refcount underflow on stm32mp1

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 4410 bytes --]

On Wed, Mar 16, 2022 at 10:44:37PM +0100, Uwe Kleine-König wrote:
> Hello Greg,
> 
> On Wed, Mar 16, 2022 at 06:09:13PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Mar 16, 2022 at 05:47:24PM +0100, Uwe Kleine-König wrote:
> > > on an stm32mp157a based machine I encounter the following problem during
> > > boot:
> > > 
> > > [    2.031752] using random self ethernet address
> > > [    2.034869] using random host ethernet address
> > > [    2.039329] using random self ethernet address
> > > [    2.043986] using random host ethernet address
> > > [    2.049186] usb0: HOST MAC 6a:74:a8:25:a5:f9
> > > [    2.052482] usb0: MAC f6:83:b5:19:02:4f
> > > [    2.056631] Mass Storage Function, version: 2009/09/11
> > > [    2.061408] LUN: removable file: (no medium)
> > > [    2.065652] no file given for LUN0
> > > [    2.111423] g_multi 49000000.usb-otg: failed to start g_multi: -22
> > > [    2.116359] ------------[ cut here ]------------
> > > [    2.120762] WARNING: CPU: 0 PID: 7 at lib/refcount.c:28 dwc2_hsotg_remove+0x1c/0x2c
> > > [    2.128541] refcount_t: underflow; use-after-free.
> > > [    2.133214] Modules linked in:
> > > [    2.136229] CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.17.0-rc8-dirty #10
> > > [    2.143351] Hardware name: STM32 (Device Tree Support)
> > > [    2.148482] Workqueue: events_unbound deferred_probe_work_func
> > > [    2.154314]  unwind_backtrace from show_stack+0x18/0x1c
> > > [    2.159515]  show_stack from dump_stack_lvl+0x40/0x4c
> > > [    2.164555]  dump_stack_lvl from __warn+0xd8/0x17c
> > > [    2.169334]  __warn from warn_slowpath_fmt+0x98/0xc8
> > > [    2.174287]  warn_slowpath_fmt from dwc2_hsotg_remove+0x1c/0x2c
> > > [    2.180196]  dwc2_hsotg_remove from dwc2_driver_probe+0x59c/0x790
> > > [    2.186278]  dwc2_driver_probe from platform_probe+0x64/0xc0
> > > [    2.191926]  platform_probe from really_probe+0x1ac/0x470
> > > [    2.197312]  really_probe from __driver_probe_device+0xa8/0x20c
> > > [    2.203220]  __driver_probe_device from driver_probe_device+0x3c/0xcc
> > > [    2.209650]  driver_probe_device from __device_attach_driver+0xac/0x124
> > > [    2.216254]  __device_attach_driver from bus_for_each_drv+0x84/0xc8
> > > [    2.222511]  bus_for_each_drv from __device_attach+0xcc/0x1d4
> > > [    2.228245]  __device_attach from bus_probe_device+0x8c/0x94
> > > [    2.233894]  bus_probe_device from deferred_probe_work_func+0x9c/0xdc
> > > [    2.240324]  deferred_probe_work_func from process_one_work+0x210/0x584
> > > [    2.246929]  process_one_work from worker_thread+0x214/0x544
> > > [    2.252576]  worker_thread from kthread+0xf0/0x120
> > > [    2.257356]  kthread from ret_from_fork+0x14/0x2c
> > > [    2.262047] Exception stack(0xc190ffb0 to 0xc190fff8)
> > > [    2.267089] ffa0:                                     00000000 00000000 00000000 00000000
> > > [    2.275260] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > [    2.283426] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > > [    2.290196] ---[ end trace 0000000000000000 ]---
> > > 
> > > This happens on v5.15 and on v5.17-rc8.
> > > 
> > > I didn't try to debug this further, just wanted to let you know ...
> > 
> > So it's always been an issue?
> > 
> > git bisect?
> 
> I don't believe this is the easiest approach to tackle that problem.
> Support for stm32mp157a was added around v5.5, but I failed to get this
> version up on my machine. v5.15 is the oldest kernel I had running on
> that machine.
> 
> The problem is that after usb_add_gadget_udc() failed in
> dwc2_driver_probe(), dwc2_hsotg_remove() -> usb_del_gadget_udc() ->
> usb_put_gadget() -> put_device() results in that underflow.
> 
> With that information I'd expect that someone understanding how
> reference counting works with usb gadgets should be able to come up with
> a fix.

The problem is that usb_add_gadget_udc() failing already calls
usb_put_gadget() and so dwc2_hsotg_remove() must not call it again when
called from dwc2_driver_probe.

I don't understand that udc stuff enough to be confident that a patch I
create for that will do the right thing.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]