On Mon, 7 Nov 2011, Sarah Sharp wrote: > > > Alan, won't this global limit on the usbfs URB buffer size effect > > > userspace drivers that are currently allocating large amounts of > > > buffers, but still respecting individual buffer limit of 16KB? It seems > > > like the patch has the potential to break userspace drivers. > > > > It might indeed. A further enhancement would replace that 16-MB global > > constant with a sysfs attribute (a writable module parameter for > > usbcore). Do you have any better suggestions? > > No, I don't have any better suggestions, except take out the limit. ;) > > I do understand why we don't want userspace to DoS the system by using > up too much DMA'able memory. However, as I understand it, the usbfs > files are created by udev with root access only by default, and distros > may choose to install rules that have more permissive privileges. A > device vendor may not be ensured that a udev rule with permissive access > will be present for their device, so I think they're likely to write > programs that require root access. Or require root privileges to > install said udev rule. > > At that point, the same userspace program that has root privileges in > order to access usbfs or create the udev rule can just load and unload > the usbcore module with an arbitrarily large global limit, and the > global limit doesn't really add any security. So why add the extra > barrier? This is a question of kernel policy, and I don't know what is the generally accepted approach to this sort of thing. Maybe Greg or Alan Cox can comment. > > > I think that Point Grey's USB 3.0 webcam will be attempting to queue a > > > series of bulk URBs that will be bigger than your 16MB global limit. > > > > For SuperSpeed, 16 MB is rather on the low side. For high speed it > > amounts to about 1/3-second worth of data, which arguably is also a bit > > low. Increasing the default is easy enough, but the best choice isn't > > obvious. > > Yeah, the choice is not obvious and we're probably going to get it > wrong, but as Tim said, he does need ~600MB in flight at once, so I knew > 16MB was too small. I guess the question really should be not "What is > the smallest limit we need?" but "When will the system start breaking > down due to memory pressure?" and set the limit somewhere pretty close > to there. It might not be so easy to identify that value. I wouldn't know how to do it. > Do other subsystems have these issues as well? Does the layer SCSI ever > limit the number of outstanding READ requests (aside from hardware > limitations)? Not as far as I know. Perhaps the block layer tries to slow things down if too many I/O operations are pending (or maybe not -- I'm not at all familiar with the details), but that's different from returning an error. > Or does the networking layer have a limit to the buffers > it keeps pending transfers for userspace to read? Again, I don't know. Those subsystems are a lot more complicated than usbfs, and they probably have arrangements to allocate intermediate buffers a piece at a time. We could do something like that, but the end result would be the same as our current limit on URB sizes -- the only difference being that transfers would be split into multiple URBs by the usbfs driver instead of by the user program. In fact, it's not all that easy for a program to generate many I/O requests concurrently. The old async I/O mechanism is one way, and you spent a lot of time working on it. Do you remember if it had any limits? 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
