Hi, (please don't top-post ;-) "Tang, Jianqiang" <jianqiang.tang@xxxxxxxxx> writes: > Hi Balbi, > > Sorry late response due to some other issues. > 1> Yes, I agree this is one gadget driver bug. > > Current gadget framework do not have any check about this > usb_request->complete pointer per my understanding. yes, and that's by design. > I think we should add some check in dwc3 OR gadget API like > usb_ep_queue() in include/linux/usb/gadget.h. I'd rather we don't. ->complete() is a required API and if there's any gadget driver not providing it, I want that gadget driver to Oops, open pandora's box, Summon Chtulhu, whatever's the worst. The reason is that lacking a ->complete() is a pretty big mistake and we better catch it as soon as possible. > I saw in 4.5-rc6 there is some sanity check code in usb_ep_queue. I > can move the check from dwc3 to gadget.h. thanks, but no thanks ;-) > 2> My current kernel is not vanilla kernel from Linus, I am using > one old/modified kernel based on 3.1x. then, I'm sorry, you're on your own here :-) > But as this bug is point to usb_request->complete is NULL, I think the > latest kernel also have the risk to happen. right, and we will keep it that way so we can be forced at looking for _that_ bug. Would you be willing to look for this bug in RNDIS driver and fix it ? > My platform is x86 platform. > And I am not able to reproduce this issue also. and how can you fix somethign you can't reproduce ? > From my analysis of call trace, I suspect there is RNDIS gadget > function is running with data transfer, also disconnect happen when > kernel panic. > > As I am not able to reproduce this issue until now, I am using my > supposed way to reproduce this issue: this is no good. If you can't reproduce the issue there's no way you can understand it well enough to fix it properly, right ? This patch should have been an RFC, considering you haven't found the root cause of the problem. > Connect device with RNDIS enabled. > Run RNDIS transfer using iperf with one Host machine as server and > client. > Disconnect device when iperf is running. and you couldn't reproduce with these steps ? What makes you think this is really the scenario which would cause the problem ? > To be clear, this is my supposed way, I am not able to reproduce this > issue also. you shouldn't have sent this patch, actually. An RFC would be fine, but the truth is that you didn't really understand the problem yet if you can't reliably reproduce it. > 3> So what is your opinion about how to fix this issue? see above -- balbi
Attachment:
signature.asc
Description: PGP signature
