[lkml]   [2011]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch] Increase USBFS Bulk Transfer size
    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

    Alan Stern

     \ /
      Last update: 2011-11-07 21:57    [W:0.024 / U:4.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site