Re: [PATCH v4 1/2] usb: gadget: udc: core: Invoke usb_gadget_connect only when started

[Badhri Jagan Sridharan]

Keeping the thread updated. I sent out
https://www.spinics.net/lists/kernel/msg4792009.html few hours earlier
and have requested help from Francesco, Alistair and others who
reported the issue.
Discussing with Alan stern on the feedback he had left.

Thanks for the support,
Badhri

On Wed, May 17, 2023 at 3:57 AM Linux regression tracking (Thorsten
Leemhuis) <regressions@xxxxxxxxxxxxx> wrote:
>
> On 17.05.23 12:35, Francesco Dolcini wrote:
> > On Wed, May 17, 2023 at 12:23:39PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> >> [CCing Francesco Dolcini; and the regression list too, as it should be
> >> in the loop for regressions:
> >> https://docs.kernel.org/admin-guide/reporting-regressions.html]
> >>
> >> On 16.05.23 14:53, Alistair wrote:
> >>> On Fri, 2023-04-07 at 03:07 +0000, Badhri Jagan Sridharan wrote:
> >>>> usb_udc_connect_control does not check to see if the udc has already
> >>>> been started. This causes gadget->ops->pullup to be called through
> >>>> usb_gadget_connect when invoked from usb_udc_vbus_handler even before
> >>>> usb_gadget_udc_start is called. Guard this by checking for udc-
> >>>>> started
> >>>> in usb_udc_connect_control before invoking usb_gadget_connect.
> >>> [...]
> >>>> Cc: stable@xxxxxxxxxxxxxxx
> >>>> Fixes: 628ef0d273a6 ("usb: udc: add usb_udc_vbus_handler")
> >>>> Signed-off-by: Badhri Jagan Sridharan <badhri@xxxxxxxxxx>
> >>>
> >>> This patch causes a kernel hang when trying to boot with the
> >>> usb/chipidea/udc.c driver.
> >>>
> >>> The call stack below causes the hang:
> >>>
> >>>  - gadget_bind_driver(struct device *dev)
> >>>     - mutex_lock(&udc->connect_lock);
> >>>     - usb_gadget_udc_start_locked(struct usb_udc *udc)
> >>>         - udc->gadget->ops->udc_start(udc->gadget, udc->driver)
> >>>
> >>> At which point we are calling ci_udc_start(..), but with the
> >>> connect_lock mutex locked.
> >>>
> >>> ci_udc_start() then calls usb_udc_vbus_handler() which tries to lock
> >>> the connect_lock while it's already locked. Resulting in a kernel hang.
> >>>
> >>> Reverting this patch fixes the hang.
> >>
> >> Not my area of expertise, but I guess it might be the same error as this
> >> one:
> >>
> >> https://lore.kernel.org/all/ZF4BvgsOyoKxdPFF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >>
> >> Francesco sent a revert on Friday, but no reaction from Badhri Jagan
> >> Sridharan or Greg yet afaics.
> >>
> >> https://lore.kernel.org/all/20230512131435.205464-1-francesco@xxxxxxxxxx/
> >
> > Revert patches were applied and are in linux-next. I expect those to
> > land in Linus tree with the next pull request from Greg.
>
> Ha, sorry, I missed that, as I only looked at lore. Should have looked
> in my own regression tracking, there it's marked as "fix incoming", as
> regzbot noticed the fix in next...
>
> Ciao, Thorsten