From: Martin Jackson <mjackson220.list@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
