09 May, 2017
1 commit
-
There are many code paths opencoding kvmalloc. Let's use the helper
instead. The main difference to kvmalloc is that those users are
usually not considering all the aspects of the memory allocator. E.g.
allocation requests
Reviewed-by: Boris Ostrovsky # Xen bits
Acked-by: Kees Cook
Acked-by: Vlastimil Babka
Acked-by: Andreas Dilger # Lustre
Acked-by: Christian Borntraeger # KVM/s390
Acked-by: Dan Williams # nvdim
Acked-by: David Sterba # btrfs
Acked-by: Ilya Dryomov # Ceph
Acked-by: Tariq Toukan # mlx4
Acked-by: Leon Romanovsky # mlx5
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Herbert Xu
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Tony Luck
Cc: "Rafael J. Wysocki"
Cc: Ben Skeggs
Cc: Kent Overstreet
Cc: Santosh Raspatur
Cc: Hariprasad S
Cc: Yishai Hadas
Cc: Oleg Drokin
Cc: "Yan, Zheng"
Cc: Alexander Viro
Cc: Alexei Starovoitov
Cc: Eric Dumazet
Cc: David Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Oct, 2016
1 commit
-
Add scomp backend for lzo compression algorithm.
Signed-off-by: Giovanni Cabiddu
Signed-off-by: Herbert Xu
15 Apr, 2016
1 commit
-
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.lzo_init uses __GFP_REPEAT to allocate LZO1X_MEM_COMPRESS 16K. This is
order 3 allocation request and __GFP_REPEAT is ignored for this size
as well as all
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Michal Hocko
Signed-off-by: Herbert Xu
24 Nov, 2014
1 commit
-
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
25 Jun, 2014
1 commit
-
kvfree() helper is now available, use it instead of open code it.
Signed-off-by: Eric Dumazet
Signed-off-by: Herbert Xu
20 Jun, 2014
1 commit
-
zswap allocates one LZO context per online cpu.
Using vmalloc() for small (16KB) memory areas has drawback of slowing
down /proc/vmallocinfo and /proc/meminfo reads, TLB pressure and poor
NUMA locality, as default NUMA policy at boot time is to interleave
pages :edumazet:~# grep lzo /proc/vmallocinfo | head -4
0xffffc90006062000-0xffffc90006067000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2
0xffffc90006067000-0xffffc9000606c000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2
0xffffc9000606c000-0xffffc90006071000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2
0xffffc90006071000-0xffffc90006076000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2This patch tries a regular kmalloc() and fallback to vmalloc in case
memory is too fragmented.Signed-off-by: Eric Dumazet
Signed-off-by: Herbert Xu
01 Aug, 2012
1 commit
-
Initialization of cra_list is currently mixed, most ciphers initialize this
field and most shashes do not. Initialization however is not needed at all
since cra_list is initialized/overwritten in __crypto_register_alg() with
list_add(). Therefore perform cleanup to remove all unneeded initializations
of this field in 'crypto/'.Signed-off-by: Jussi Kivilinna
Signed-off-by: Herbert Xu
21 Apr, 2008
1 commit
-
On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
> Kamalesh Babulal wrote:
>
> > This patch cleanups the crypto code, replaces the init() and fini()
> > with the _init/_fini
>
> This part ist OK.
>
> > or init/fini_ (if the
> > _init/_fini exist)
>
> Having init_foo and foo_init won't be a good thing, will it? I'd start
> confusing them.
>
> What about foo_modinit instead?Thanks for the suggestion, the init() is replaced with
_mod_init ()
and fini () is replaced with _mod_fini.
Signed-off-by: Kamalesh Babulal
Signed-off-by: Herbert Xu
11 Jan, 2008
1 commit
-
Add LZO compression algorithm support
Signed-off-by: Zoltan Sogor
Signed-off-by: Herbert Xu