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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Jun 2011 23:17:54 +0200 From: Martin Jackson <mjackson220.list@...il.com> To: James Carlson <carlsonj@...kingcode.com> Cc: paulus@...ba.org, linux-ppp@...r.kernel.org, netdev@...r.kernel.org Subject: Re: ppp_deflate + kmalloc On Fri, Jun 24, 2011 at 4:02 PM, James Carlson <carlsonj@...kingcode.com> wrote: > Martin Jackson wrote: >> In our android froyo-based system (omap3 hardware), we are getting the >> following problem where the ppp driver cannot kmalloc enough memory >> for the decomp buffer in the ppp driver. >> >> Trying to make a 4th-order kmalloc (I think that amounts to 64kB) >> seems ambitious. I do not understand why vmalloc is not being used >> here, like it is for the compression buffer. Is using vmalloc here an >> acceptable solution? > > The code here shouldn't need contiguous pages, so vmalloc (even if > "slower") shouldn't be a problem. > > But a higher-level question might be why you're bothering with RFC 1979 > Deflate compression at all on this platform. I'd expect that you're > most likely going to end up talking to commercially-produced PPP servers > (possibly 3GPP or similar) at the other end, and very, very few of them > offer data compression with either RFC 1977 (BSD Compression) or RFC > 1979. ("Very, very few" is probably being generous ...) > > If it's always going to be negotiated away in practice, and if you're > having trouble with memory constraints, why not just ditch the baggage? > > -- > James Carlson 42.703N 71.076W <carlsonj@...kingcode.com> > 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. Best regards, Martin Jackson -- 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
Powered by blists - more mailing lists