On Mon, Jul 22, 2024 at 01:11:01PM -0400, Chris Wulff wrote: > On Mon, Jul 22, 2024 at 9:38 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, Jul 22, 2024 at 09:00:07AM -0400, Chris Wulff wrote: > > > On Sun, Jul 21, 2024 at 9:07 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Sun, Jul 21, 2024 at 03:20:49PM -0400, crwulff@xxxxxxxxx wrote: > > > > > From: Chris Wulff <crwulff@xxxxxxxxx> > ... > > > The previous check was also hiding the error, and introduced a panic. > > > I could add a printk to that error case, though it would be unassociated > > > with the gadget that caused the problem. This function does also return > > > an error code when it fails, so the calling function can check that and > > > print an error. > > > > Okay. It wouldn't hurt to print out an error message, even if there's > > no way to tell which gadget it refers to. A dump_stack() would help in > > that regard, but it won't be needed if the guilty party will always be > > pretty obvious. > > > > By the way, how did you manage to trigger this error? None of the > > in-kernel gadget drivers are known to have this bug, and both the > > gadgetfs and raw_gadget drivers prevent userspace from doing it. Were > > you testing a gadget driver that was under development? > > I am working on adding alternate settings to UAC1/2 gadgets, so this really > was a case of trying to make the failure in development easier to deal with. > I don't believe there are any problems with existing gadgets causing this. > > I will add an error message and submit a new version. Perhaps > WARN_ON_ONCE would be appropriate here to get that backtrace > instead of a printk? That sounds good. You should also mention in the patch description that the purpose is to prevent undebuggable panics during driver development, and no existing drivers will trigger the warning. Alan Stern
