[crypto:master 8/8] ERROR: "adf_init_pf_wq" [drivers/crypto/qat/qat_common/intel_qat.ko] undefined!

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git master head: 9e209fcfb804da262e38e5cd2e680c47a41f0f95 commit: 9e209fcfb804da262e38e5cd2e680c47a41f0f95 [8/8] crypto: qat - fix invalid pf2vf_resp_wq logic config: x86_64-randconfig-s4-05031238 (attached as .config)

Re: skcipher

Am Dienstag, 3. Mai 2016, 10:34:01 schrieb Gadre Nayan: Hi Gadre, > Hello, > > I tried few combinations of algorithms: > > 1. skcipher = crypto_alloc_skcipher("aes", 0, 0); > > could not allocate skcipher handle: -2 > lsmod: > aes_i586 20480 0 Please read the documentation and

Re: skcipher

Hello, I tried few combinations of algorithms: 1. skcipher = crypto_alloc_skcipher("aes", 0, 0); could not allocate skcipher handle: -2 lsmod: aes_i586 20480 0 2. skcipher = crypto_alloc_skcipher("cbc(aes)", 0, 0); So here all allocations work but, in test_skcipher_encdec this

Re: skcipher

Am Montag, 2. Mai 2016, 21:00:25 schrieb Gadre Nayan: Hi Gadre, > Hi Stephan, > > I checked modinfo aesni_intel: > filename: /lib/modules/4.5.0/kernel/arch/x86/crypto/aesni-intel.ko > alias: crypto-aes > alias: aes > license:GPL > description:Rijndael (AES)

Re: skcipher

Hi Stephan, I checked modinfo aesni_intel: filename: /lib/modules/4.5.0/kernel/arch/x86/crypto/aesni-intel.ko alias: crypto-aes alias: aes license:GPL description:Rijndael (AES) Cipher Algorithm, Intel AES-NI instructions optimized alias: crypto-fpu

Re: [PATCH] crypto: constify ccp_actions structure

On 05/01/2016 06:52 AM, Julia Lawall wrote: The ccp_actions structure is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall Acked-by: Gary Hook --- drivers/crypto/ccp/ccp-dev-v3.c |2 +-

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 09:48:57 schrieb Theodore Ts'o: Hi Theodore, > On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote: > > > - entropy pool draining: when having a timer-based reseeding on a quiet > > > system, the entropy pool can be drained during the expiry of the timer. > > >

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote: > > - entropy pool draining: when having a timer-based reseeding on a quiet > > system, the entropy pool can be drained during the expiry of the timer. So, > > I > > tried to handle that by increasing the timer by, say, 100 seconds

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

On Mon, May 02, 2016 at 11:14:25AM +0200, Stephan Mueller wrote: > The issue of rollback (if you refer to activating an earlier saved image of > the guest) is a real issue the guest cannot do anything about it that is > effective (i.e. the guest can do without the help of the VMM). Note,

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

On Mon, May 02, 2016 at 09:00:22AM +0200, Stephan Mueller wrote: > - reseed avalanche: I see that you added a time-based reseed code too (I am > glad about that one). What I fear is that there is a reseed avalanche when > the > various RNGs are seeded initially closely after each other (and

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o wrote: > From: Stephan Mueller > > The Hyper-V Linux Integration Services use the VMBus implementation for > communication with the Hypervisor. VMBus registers its own interrupt > handler that completely bypasses

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 02:26:52 schrieb Theodore Ts'o: Hi Theodore, I have not digested the patch set yet, but I have the following questions to your patch set. > On a system with a 4 socket (NUMA) system where a large number of > application processes were all trying to read from

[PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

On a system with a 4 socket (NUMA) system where a large number of application processes were all trying to read from /dev/urandom, this can result in the system spending 80% of its time contending on the global urandom spinlock. The application have used its own PRNG, but let's try to help it

[PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

From: Stephan Mueller The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy

[PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o --- crypto/chacha20_generic.c | 61 -- drivers/char/random.c | 282 ++ include/crypto/chacha20.h | 1 +

[RFC PATCH 0/3] random: replace urandom pool with a CRNG

Everyone is consing up their own random patches, so this is my set. :-) By using a CRNG to replace the urandom pool, we address a number of complaints which Stephan Mueller has been concerned about. We now use a much more aggressive interrupt sampling system to quickly initialize a CRNG which