On Wed, 6 Jun 2018, Andrey Konovalov wrote: > On Tue, Jun 5, 2018 at 10:06 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 5 Jun 2018, Andrey Konovalov wrote: > > [...] > > > What do you need that's different from what gadgetfs provides? > > 1. It does some sanity checks on the provided USB descriptors, which > we don't really want, since providing improper descriptors is a way to > find bugs. > > 2. Replies to some USB requests without asking the user. Same thing, > giving the user (== syzkaller) to reply something improper can trigger > some bugs. > > 3. File based interface is somewhat inconvenient for integration with syzkaller. > > (4. Doesn't support SuperSpeed and doesn't support multiple UDC > devices. This can be fixed of course. ) > > Basically what (I think) I want is an ioctl-based GadgetFS-like > interface, that doesn't implement any USB protocol logic, but simply > passes all received requests to the user and asks for replies. I see. Yes, hacking the gadgetfs driver is going to be the quickest way to get that sort of interface. > >> Could you elaborate on this? AFAIU the dummy device contains both a > >> virtual UDC and a virtual HCD that are connected to each other and > >> allow to plug a gadget device into usb core within the kernel. How do > >> you test a driver for an actual host controller? Is there a way to > >> connect a dummy UDC with an actual HCD? > > > > You can't connect a dummy UDC to an actual HCD. But you can connect an > > actual UDC to an actual HCD -- people do it all the time. > > > > Normally the UDC and the HCD reside on separate computers. For > > example, mobile devices typically have UDCs, and you can connect them > > to PCs. But there is also UDC hardware available for Linux on Intel > > systems, so you can have the UDC and the HCD in the same computer if > > that's what you want. Or two separate PCs, both running Linux. Or > > even a Linux PC gadget connected to a Windows or OS X host! > > I see, but that all requires real hardware, right? You can't just run > it in a VM (that's what I'm planning to do with dummy_hcd)? Not unless the hypervisor has virtualized the UDC (which I doubt any of them do.) Still, it might be worthwhile running some tests on bare metal, even if that means only doing one test at a time. > [...] > > > Right. For example, usb-storage uses a work-queue routine for SCSI > > scanning when a new device is probed. And in that routine, the SCSI > > layer often delegates some of the scanning work to async helper > > threads, depending on the how the system is configured. > > Could you point me to the code that does that? I mean SCSI scanning. SCSI scanning is done by several routines in drivers/scsi/scsi_scan.c. The initial entry point is scsi_scan_host(). > [...] > > >> 2. All the virtual UDCs get the same name "dummy_udc". And since the > >> process of UDC lookup to bind a gadget driver is based on the UDC name > >> (see usb_gadget_probe_driver()), we can't bind different gadget > >> drivers to different UDCs (and therefore connect to different hubs). > > > > That can be changed pretty easily. For virtual UDCs beyond the first, > > we could append "-2", "-3", and so on to the "dummy_udc" name, for > > example. > > I wrote a patch to implement this and then realized that it's actually > not needed. Even though all UDC devices have the same name > "dummy_udc", it seems they are actually renamed by someone and end up > getting names "dummy_udc.0", "dummy_udc.1" and so on (that'w what I > see when I add printk to usb_gadget_probe_driver()). Probably the platform driver core does this. > What initially confused me was that gadgetfs always binds to the same > UDC, but that's because it doesn't set the udc_name field of the > usb_gadget_driver struct (and also because it always expects the UDC > name to be the one returned by usb_get_gadget_udc_name(), but that > part I patched when I was trying to bind it to some other UDC). If a gadget driver don't specify the udc_name then it binds to the first available UDC. So if you load some other gadget driver (such as g_zero) before gadgetfs, then gadgetfs would bind to the second UDC. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
