On Tue, May 11, 2021 at 10:53:22AM +0800, Peter Chen wrote:
> Hi Alan,
>
> I fixed a similar issue for configfs, see 1a1c851bbd70
> ("usb: gadget: configfs: fix concurrent issue between composite APIs")
Yes, I see. That is indeed the very same problem.
> It doesn't prevent disconnect callback, the disconnect callback will check
> if unbind has called. The same for .setup and .suspend. Did you see
> issues using configfs or legacy gadget? For legacy gadget, just like you said
> it is the second disconnect callback is called during the removal process,
> the first is called at usb_gadget_disconnect. It is not easy to prevent disconnect
> occurring, we could add some logic at composite_disconnect, and let it quit if it is
> called the second time.
I haven't seen the race occur in operation. It was only theoretical; I
noticed it while thinking about one of the commits that was just merged
into the -stable kernels.
> It is hard to avoid usb_gadget_driver callback until usb_gadget_udc_stop has called,
> no matter bad hardware or threaded interrupts, my former solution is avoid
> dereferenced pointer issue, most of callbacks handling are useless if the gadget has already
> unbind, the only meaningful callback is disconnect, and we have already called it
> at usb_gadget_disconnect
Agreed.
I suppose we could do something similar for the composite driver, for
gadgets that don't use configfs. But what about legacy gadgets? Are
there any still around that don't use either configfs or the composite
framework?
Alan Stern
