On Fri, 16 Dec 2011, Sarah Sharp wrote:
> When running the Point Grey "flycap" program for their USB 3.0 camera
> (which was running as a USB 2.0 device for some reason), I trigger this
> oops whenever I try to open a video stream:
...
> markup_oops.pl says the oops is in put_cred:
...
> This bug seems to have been introduced by commit
> d178bc3a708f39cbfefc3fab37032d3f2511b4ec "user namespace: usb: make usb
> urbs user namespace aware (v2)"
>
> I'm not sure if this is right fix, but it does stop the oops.
>
> Unfortunately, the Point Grey software still refuses to work, but it's a
> closed source app, so I can't fix it.
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
> Cc: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>
> ---
> drivers/usb/core/devio.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index d8cf06f..3af5e2d 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -286,7 +286,8 @@ static struct async *alloc_async(unsigned int numisoframes)
> static void free_async(struct async *as)
> {
> put_pid(as->pid);
> - put_cred(as->cred);
> + if (as->cred)
> + put_cred(as->cred);
> kfree(as->urb->transfer_buffer);
> kfree(as->urb->setup_packet);
> usb_free_urb(as->urb);
This is a reasonable fix. It turns out there are a couple of error
paths by which a struct async can be freed before its .cred member has
been set. The alternative fix is to move the statement initializing
as->cred up earlier, before those errors occur. But what you did is
probably more robust.
The most likely error, which didn't exist when commit d178bc3a708f39
was written, is that the usbfs memory limit was exceeded. You can see
if increasing that limit helps "flycap" at all. (The other error path
happens when kmalloc fails to get enough memory for the URB's transfer
buffer.)
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
