03 Aug, 2017

3 commits

  • The scompress code allocates 2 x 128 KB of scratch buffers for each CPU,
    so that clients of the async API can use synchronous implementations
    even from atomic context. However, on systems such as Cavium Thunderx
    (which has 96 cores), this adds up to a non-negligible 24 MB. Also,
    32-bit systems may prefer to use their precious vmalloc space for other
    things,especially since there don't appear to be any clients for the
    async compression API yet.

    So let's defer allocation of the scratch buffers until the first time
    we allocate an acompress cipher based on an scompress implementation.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • When allocating the per-CPU scratch buffers, we allocate the source
    and destination buffers separately, but bail immediately if the second
    allocation fails, without freeing the first one. Fix that.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • Due to the use of per-CPU buffers, scomp_acomp_comp_decomp() executes
    with preemption disabled, and so whether the CRYPTO_TFM_REQ_MAY_SLEEP
    flag is set is irrelevant, since we cannot sleep anyway. So disregard
    the flag, and use GFP_ATOMIC unconditionally.

    Cc: # v4.10+
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

24 Apr, 2017

1 commit


13 Jan, 2017

1 commit

  • Continuing from this commit: 52f5684c8e1e
    ("kernel: use macros from compiler.h instead of __attribute__((...))")

    I submitted 4 total patches. They are part of task I've taken up to
    increase compiler portability in the kernel. I've cleaned up the
    subsystems under /kernel /mm /block and /security, this patch targets
    /crypto.

    There is which provides macros for various gcc specific
    constructs. Eg: __weak for __attribute__((weak)). I've cleaned all
    instances of gcc specific attributes with the right macros for the crypto
    subsystem.

    I had to make one additional change into compiler-gcc.h for the case when
    one wants to use this: __attribute__((aligned) and not specify an alignment
    factor. From the gcc docs, this will result in the largest alignment for
    that data type on the target machine so I've named the macro
    __aligned_largest. Please advise if another name is more appropriate.

    Signed-off-by: Gideon Israel Dsouza
    Signed-off-by: Herbert Xu

    Gideon Israel Dsouza
     

25 Oct, 2016

1 commit