netdev - RE: usbnet OOM handling - possible CPU starvation?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Mar 2014 10:29:50 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Bjørn Mork' <bjorn@...k.no>,
	Oliver Neukum <oneukum@...e.de>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: RE: usbnet OOM handling - possible CPU starvation?

From: Bjørn Mork
> Hello Oliver & other clueful gurus!
> 
> I started looking at how to improve the OOM handling in usbnet, but have
> to admit that this is way over my head. I don't think I dare touching
> it...
> 
> I've seen a few reports clearly showing that we do have a problem. One
> example is here: http://forums.whirlpool.net.au/forum-replies.cfm?t=2207038&p=57#r1122
> 
> Although all the reports I've seen are from users of cdc_ncm, I don't
> think this problem is specific to any particualar minidriver. But it is
> of course easier to trigger it using a minidriver with (too?)  large
> buffers, like the cdc_ncm minidriver family.
> 
> To recall: The NCM and MBIM protocols aggregate packets before
> transission over the USB link, requiring USB buffers with multiple
> ethernet/IP packets.  Common code used by both cdc_mbim and cdc_ncm
> currently cap the buffers at 32768 bytes (hard coded limit), which is
> still too high for some embedded hosts.  This results in failures to
> allocate buffers in rx_submit (flags == GFP_ATOMIC when it is called
> from the URB callback):

I think that some of these drivers need to use a slightly different
buffer scheme to the one that usbnet currently supports.

In many cases the usb hardware will aggregate many receive frames into
a single USB bulk packet, and also supports the driver aggregating multiple
transmit frames.
Not all the stub drivers aggregate transmit packets.

It really doesn't make much sense (to me) to transmit and receive
aggregated packets from dynamically allocated skb.
I'd have thought it much better to copy the ethernet frames to/from
pre-allocated buffers.
Yes, you take the cost of a data copy, but for USB2 the data rate
isn't that high, and USB3 ought to be able to do scatter-gather
transmit (when xhci is fixed).

The transmit side could have 2 buffers, and at most one active urb.
So merges until the previous tx finishes (or 3 buffers and two
active tx).

The rx side needs a few buffers that are multiples of the usb
transfer size - so that long usb bulk data packets can end up
in multiple urb, and then get merged into a single skb correctly
sized for the ethernet frame.
For USB2 maybe you could use 1536 byte skb - but I expect that
you still want to copy short frames.

At the moment some driver allocate very large rx skb - and then
lie about their truesize.
If any devices actually do receive segment offload (the ax88179
does TSO, don't know about the rx side), then using large skb
for the rx side just in case they are very long packets when
they can be passed directly up the stack.

	David