From: Martin Jackson <redacted>
Date: Sun, 26 Jun 2011 23:17:54 +0200

Thanks for the advice. Hopefully we can indeed remove these obscure
PPP options from our configuration - I'll look into that.

However, the point still stands that a 4th order kmalloc is likely to
fail (even our "embedded" device has 256MB RAM and slub allocator,
after all), and the page allocation code regards anything above order
3 as unrealistic and doesn't invoke the OOM to try to satisfy it, so
my view remains that this should be changed to vmalloc.

PPP is not the only place in the tree where we potentially have
this problem.

crypto/deflate.c:	stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
crypto/zlib.c:	stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
drivers/net/bnx2x/bnx2x_main.c:	bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(),
drivers/net/ppp_deflate.c:	state->strm.workspace = kmalloc(zlib_inflate_workspacesize(),
fs/binfmt_flat.c:	strm.workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
lib/zlib_inflate/infutil.c:	strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);

A particularly problematic case is binfmt_flat.c since this is used on
systems which lack an MMU, and therefore for which vmalloc() is not
applicable.

What I'll do for now is transform all of the networking cases, but
someone should think seriously about the remaining cases.