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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 26 Jun 2011 23:17:54 +0200
From:	Martin Jackson <>
To:	James Carlson <>
Subject: Re: ppp_deflate + kmalloc

On Fri, Jun 24, 2011 at 4:02 PM, James Carlson <> 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         <>

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
More majordomo info at

Powered by blists - more mailing lists