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] [day] [month] [year] [list]

Date:	Tue, 18 Mar 2014 12:01:03 +0100
From:	Oliver Neukum <oneukum@...e.de>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	'Bjørn Mork' <bjorn@...k.no>,
	"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?

On Tue, 2014-03-18 at 10:29 +0000, David Laight wrote:
> From: Bjørn Mork

Hi,

> > 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):

True. We cannot rely on this working from a callback. So the correct
OOM response would happen from a delayed work queue.

> 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.

That makes sense.

> 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).

We had bad experiences with that scheme. It turns out that you
need to have two URBs in flight, because the time you lose waiting
for the next frame to begin is too high.
So you need at least three buffers. 

	Regards
		Oliver


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html