Re: [PATCH] Memory leak in visor.c and ftdi_sio.c

From: nardelli (jnardelli_at_infosciences.com)
Date: 06/07/04

  • Next message: Sebastian Kloska: "Re: APM realy sucks on 2.6.x"
    Date:	Mon, 07 Jun 2004 10:19:30 -0400
    To: Greg KH <greg@kroah.com>
    
    

    Greg KH wrote:
    > On Fri, Jun 04, 2004 at 05:34:41PM +0100, Ian Abbott wrote:
    >
    >>On 04/06/2004 15:59, nardelli wrote:
    >>
    >>A related problem with the current implementation is that is easy to
    >>run out of memory by running something similar to this:
    >>
    >> # cat /dev/zero > /dev/ttyUSB0
    >>
    >>That affects both the ftdi_sio and visor drivers.
    >
    >
    > Care to try out the following (build test only) patch to the visor
    > driver to see if it prevents this from happening? I don't have a
    > working visor right now to test it out myself :(
    >
    > Oops, ignore the fact that we never free the structure on disconnect, I
    > see that now...
    >
    > thanks,
    >
    > greg k-h
    >
    >
    > ===== drivers/usb/serial/visor.c 1.114 vs edited =====
    > --- 1.114/drivers/usb/serial/visor.c Fri Jun 4 07:13:10 2004
    > +++ edited/drivers/usb/serial/visor.c Fri Jun 4 17:12:53 2004

    ...

    Just curious - is there something special about 42? Grepping wasn't
    very useful, as numbers like this are scattered all over the place.

    > +/* number of outstanding urbs to prevent userspace DoS from happening */
    > +#define URB_UPPER_LIMIT 42

    ...

    >
    > static int visor_write (struct usb_serial_port *port, int from_user, const unsigned char *buf, int count)
    > {
    > + struct visor_private *priv = usb_get_serial_port_data(port);
    > struct usb_serial *serial = port->serial;
    > struct urb *urb;
    > unsigned char *buffer;
    > + unsigned long flags;
    > int status;
    >
    > dbg("%s - port %d", __FUNCTION__, port->number);
    >
    > + spin_lock_irqsave(&priv->lock, flags);
    > + if (priv->outstanding_urbs > URB_UPPER_LIMIT) {
    > + spin_unlock_irqrestore(&priv->lock, flags);
    > + dev_dbg(&port->dev, "write limit hit\n");
    > + return 0;
    > + }
    > + ++priv->outstanding_urbs;
    > + spin_unlock_irqrestore(&priv->lock, flags);
    > +
    > buffer = kmalloc (count, GFP_ATOMIC);
    > if (!buffer) {
    > dev_err(&port->dev, "out of memory\n");
    > @@ -520,7 +545,10 @@
    > count = status;
    > kfree (buffer);
    > } else {
    > - bytes_out += count;
    > + spin_lock_irqsave(&priv->lock, flags);
    > + ++priv->outstanding_urbs;
    > + priv->bytes_out += count;
    > + spin_unlock_irqrestore(&priv->lock, flags);
    > }
    >
    > /* we are done with this urb, so let the host driver

    Removing the first of two priv->outstanding_urbs increments in
    visor_write (I assume that was your intention) produced very nice
    results ;-)

    1) When being flooded, after the initial bunch of URBs were sent,
    only 1 per second was sent, and it appeared that all of them were
    being freed.
    2) Even after the flood, the driver survived, and backups were
    possible after the device was reconnected.

    I'm fairly ignorant of most of the lower level usb infrastructure
    (hcd, hub, ehci, etc), so I'm not sure what the root cause (ignoring
    the patch above) of the completion handler not being called might be.
    I would suspect overflow of some callback list, but that's just a
    guess. Do you have any ideas on what this might be, and could this
    be a problem in other devices?

    -- 
    Joe Nardelli
    jnardelli@infosciences.com
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Sebastian Kloska: "Re: APM realy sucks on 2.6.x"

    Relevant Pages

    • Re: [PATCH] fix error handling in bus_add_device
      ... Greg KH wrote: ... I don't care either way, I just want to have it consistent. ... patch attached. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Linux 2.6.11.2
      ... Greg, I have now pretty well confirmed that this patch is what caused ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2.4] jffs2 aligment problems
      ... On Monday 07 June 2004 17:08, Greg Weeks wrote: ... > XScale board. ... I just got pinged that I was supposed to post this patch ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Sort generic PCI fixups after specific ones
      ... Greg, can you apply ... Ivan's patch, please? ... "Next the statesmen will invent cheap lies, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup
      ... the -fix patch for this one. ... Greg: do it in udev ... but people want to run old distros in containers ... I have basically three objections against LSM. ...
      (Linux-Kernel)