On Friday 25 January 2013 08:13:15 Bjørn Mork wrote: > Oliver Neukum <oliver@xxxxxxxxxx> writes: > > On Thursday 24 January 2013 20:16:56 Bjørn Mork wrote: > >> A device sending 0 length frames as fast as it can has been > >> observed killing the host system due to the resulting memory > >> pressure. > >> > >> Temporarily disable RX skb allocation and URB submission when > >> the current error ratio is high, preventing us from trying to > >> allocate an infinite number of skbs. Reenable as soon as we > >> are finished processing the done queue, allowing the device > >> to continue working after short error bursts. > >> > >> Signed-off-by: Bjørn Mork <bjorn@xxxxxxx> > >> --- > >> So is this starting to look OK? > > > > It seems to me that we at least need to try some error recovery. > > Won't the disabling code in usbnet_bh do? RX will only stay disabled > until the done queue is handled. So will the burst of bogus packets stop by itself? > > > How about resetting the device when it is no longer used? > > Yes, that we should do. I guess usbnet_open is the place to reset the > flag and counters? I'll send another version taking care of this and > Joes comment. I was thinking about resetting the device, not just counters. But yes, open() needs to reset the counters, too. Regards Oliver -- 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
