Re: [PATCH v2] crypto: x86/aegis,morus - Fix and simplify CPUID checks

MORUS implementations") > Signed-off-by: Ondrej Mosnacek I tried this patch on x86_64 with AES-NI and also on system with SSE but without AES-NI and it works as expected now (module is loaded only on demand and optimized one is used if available). If it is worth it, add Tested-by: Mi

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote: ... >> Are there other crypto drivers doing this? > > I thought the exact same thing until I ran into a presentation about the s390 > secure keys implementation. I basically imitated their use (or abuse?) > of the Crypto API > assuming it is the way

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Mike and others, did anyone even try to run veritysetup tests? We have verity-compat-test in our testsuite, is has even basic FEC tests included. We just added userspace verification of FEC RS codes to compare if kernel behaves the same. I tried to apply three last dm-verity patches from

[PATCH] crypto: Allow ecb(cipher_null) in FIPS mode

benchmark -c null Signed-off-by: Milan Broz <gmazyl...@gmail.com> --- crypto/testmgr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index f9c378af3907..5075e4d982ee 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2875,6 +2875,7 @@ static const

Re: [RFC PATCH v5] IV Generation algorithms for dm-crypt

On 04/07/2017 12:47 PM, Binoy Jayan wrote: > === > dm-crypt optimization for larger block sizes > === ... > Tests with dd [direct i/o] > >

Re: [PATCH] crypto: Add ECB dependency for XTS mode

Patch below should be backported to 4.10 stable (only 4.10, older kernels are ok). We have reports some systems fail to boot from LUKS now (missing ecb module in initramdisk) ... Upstream commit is 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 Thanks, Milan On 02/23/2017 08:38 AM, Milan Broz wrote

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 02:04 PM, Milan Broz wrote: > On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: > ... > >> I can certainly understand if you don't wont to take the patch until >> we have results with >> dm-crypt itself but the difference between 8 separate invocati

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: ... > I can certainly understand if you don't wont to take the patch until > we have results with > dm-crypt itself but the difference between 8 separate invocation of > the engine for 512 > bytes of XTS and a single invocation for 4KB are pretty

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote: > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz <gmazyl...@gmail.com> wrote: >> >> On 02/22/2017 07:12 AM, Binoy Jayan wrote: >>> >>> I was wondering if this is near to be ready for submission (apart from &

[PATCH] crypto: Add ECB dependency for XTS mode

Since the commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40 crypto: xts - Convert to skcipher the XTS mode is based on ECB, so the mode must select ECB otherwise it can fail to initialize. Signed-off-by: Milan Broz <gmazyl...@gmail.com> --- crypto/Kconfig | 1 + 1 file changed, 1 ins

Re: crypto: xts: regression in 4.10

On 02/22/2017 12:17 AM, Nicolas Porcel wrote: > Hello, > > I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10, > the partition cannot be opened and I have the following errors when > booting: > > device-mapper: table: 253:0: crypt: Error allocating crypto tfm >

Re: [PATCH v3] dm: switch dm-verity to async hash crypto API

; CC: Eric Biggers <ebigge...@gmail.com> > CC: Ondrej Mosnáček <omosnacek+linux-cry...@gmail.com> > CC: Milan Broz <gmazyl...@gmail.com> > --- > > The patch was tested on an Armv7 based dual core Zynq ZC706 development > board with SHA256-asm, SHA256-neon sync

Re: [PATCH v2] dm: switch dm-verity to async hash crypto API

On 02/06/2017 02:58 PM, Gilad Ben-Yossef wrote: > Use of the synchronous digest API limits dm-verity to using pure > CPU based algorithm providers and rules out the use of off CPU > algorithm providers which are normally asynchronous by nature, > potentially freeing CPU cycles. > > This can

Re: dm-crypt optimization

On 12/20/2016 10:41 AM, Binoy Jayan wrote: > At a high level the goal is to maximize the size of data blocks that get > passed > to hardware accelerators, minimizing the overhead from setting up and tearing > down operations in the hardware. Currently dm-crypt itself is a big blocker as > it

Re: [PATCH] crypto: skcipher - fix crash in virtual walk

t;buffer == walk->page, it appears to be the intention >> that walk->buffer point to walk->page after skcipher_next_slow(), so >> ensure that is the case. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > > Patch applied. Thanks. Fixed pr

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

On 12/13/2016 09:49 AM, Binoy Jayan wrote: > Currently, the iv generation algorithms are implemented in dm-crypt.c. > The goal is to move these algorithms from the dm layer to the kernel > crypto layer by implementing them as template ciphers so they can be > implemented in hardware for

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 05/27/2016 09:04 AM, Baolin Wang wrote: > Hi Milan, > > On 27 May 2016 at 14:31, Milan Broz <gmazyl...@gmail.com> wrote: >> On 05/25/2016 08:12 AM, Baolin Wang wrote: >>> Now some cipher hardware engines prefer to handle bulk block rather than one >>>

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 05/25/2016 08:12 AM, Baolin Wang wrote: > Now some cipher hardware engines prefer to handle bulk block rather than one > sector (512 bytes) created by dm-crypt, cause these cipher engines can handle > the intermediate values (IV) by themselves in one bulk block. This means we > can increase the

Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework

> > As a DM mainatiner my only contribution to this line of discussion was > relative to your proposal to train the dm-crypt target (which is > bio-based) to also provide request-based support, see: > https://www.redhat.com/archives/dm-devel/2015-November/msg00112.html > > But follow-up di

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

On 04/18/2016 02:54 PM, Sasha Levin wrote: > On 04/18/2016 05:48 AM, Thomas D. wrote: >> Hi, >> >> Milan's patches apply against 3.18.30, however I am getting build errors: > > Milan, Herbert, should I just be reverting the offending patches: > > bcfa841 crypto: af_alg - Forbid bind(2) when

Re: [PATCH 1/4] crypto: algif_skcipher - Require setkey before accept(2)

On 02/27/2016 10:40 PM, Sasha Levin wrote: > On 02/26/2016 06:44 AM, Milan Broz wrote: >> From: Herbert Xu <herb...@gondor.apana.org.au> >> >> commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream. >> >> Some cipher implementations will cras

[PATCH 3/4] crypto: algif_skcipher - Remove custom release parent function

From: Herbert Xu commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream. This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Cc: sta...@vger.kernel.org Signed-off-by:

[PATCH 2/4] crypto: algif_skcipher - Add nokey compatibility path

From: Herbert Xu commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream. This patch adds a compatibility path to support old applications that do acept(2) before setkey. Cc: sta...@vger.kernel.org Signed-off-by: Herbert Xu

[PATCH 4/4] crypto: algif_skcipher - Fix race condition in skcipher_check_key

From: Herbert Xu commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream. We need to lock the child socket in skcipher_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Cc: sta...@vger.kernel.org

[PATCH 1/4] crypto: algif_skcipher - Require setkey before accept(2)

ENOKEY if setkey hasn't been done on the socket yet. Cc: sta...@vger.kernel.org Reported-by: Dmitry Vyukov <dvyu...@google.com> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> Tested-by: Dmitry Vyukov <dvyu...@google.com> [backported to 4.1 by Milan B

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

On 02/24/2016 09:32 AM, Jiri Slaby wrote: >> +af_alg_release_parent(sk); > > and this occurs to me like a double release? yes, my copy mistake. Anyway, there should be also two more patches from series. If it helps, I copied proper backport here (upstream commit is referenced in header)

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

On 02/21/2016 05:40 PM, Milan Broz wrote: > On 02/20/2016 03:33 PM, Thomas D. wrote: >> Hi, >> >> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected. >> >> v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3. >> >> v3.

[PATCH] Re: Broken userspace crypto in linux-4.1.18

On 02/20/2016 03:33 PM, Thomas D. wrote: > Hi, > > FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected. > > v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3. > > v3.12.54 works because it doesn't contain the patch in question. Hi, indeed, because whoever backported

Re: [PATCH 1/2] crypto: af_alg - Add nokey compatibility path

On 01/04/2016 05:35 AM, Herbert Xu wrote: > On Sun, Jan 03, 2016 at 10:42:28AM +0100, Milan Broz wrote: >> >> yes, basically it prepares socket()/bind()/accept() and then it calls setkey >> once. >> (I'll try to fix in next releases to call setkey first though.) &

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively >> using that code. >> This is clear userspace breakage which should not happen thi

Re: next-20151231 - aes crypto algorithm went missing?

On 01/03/2016 06:34 AM, Valdis Kletnieks wrote: > So booting into a next-20151222 kernel, I can mount an external drive > that uses cryptLuks. I try -1231, and I get this failure: > > Failed to setup dm-crypt key mapping for device /dev/sdb2. > Check that kernel supports aes-cbc-essiv:sha256

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/02/2016 12:52 PM, Milan Broz wrote: > On 12/25/2015 08:40 AM, Herbert Xu wrote: >> Dmitry Vyukov <dvyu...@google.com> wrote: >>> >>> I am testing with your two patches: >>> crypto: algif_skcipher - Use new skcipher interface >>> cryp

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 12/25/2015 08:40 AM, Herbert Xu wrote: > Dmitry Vyukov wrote: >> >> I am testing with your two patches: >> crypto: algif_skcipher - Use new skcipher interface >> crypto: algif_skcipher - Require setkey before accept(2) >> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/02/2016 09:03 PM, Stephan Mueller wrote: > Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz: > > Hi Milan, > ... >>> Hi Herbert, >>> >>> this patch breaks userspace in cryptsetup... >>> >>> We use algif_skcipher in cryptsetu

Re: Cipher block questions

On 04/21/2015 09:27 AM, jonathan.thieul...@gmail.com wrote: I'm implementing a new cipher block within the kernel and I'm stuck into a problem. My algorithm works pretty well, it can cipher and decipher a block. The algorithm also works with ECB, CBC, and CTR modes, however when I try to use

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

On 03/02/2015 02:25 PM, Horia Geantă wrote: On 2/20/2015 7:00 PM, Martin Hicks wrote: This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2. One of the nice things about this hardware is that it knows how to deal with encrypt/decrypt requests that are larger than sector size, but

Re: [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version

. I did not have time to check it more in detail (we are always encrypting the whole sector so this should not happen... but apparently it does.) Tested-by: Milan Broz gmazyl...@gmail.com Thanks, Milan Thanks, Ard. arch/arm/crypto/aesbs-core.S_shipped | 12 arch/arm/crypto

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

On 02/24/2015 12:02 AM, Johannes Ernst wrote: All in one place: dd if=/dev/zero of=./test.img count=8 bs=1M cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img Used password ‘asdf’ (no quotes) cryptsetup open test.img test Enter passphrase for test.img: No key available

Re: [dm-crypt] cryptsetup problem on Raspberry Pi 2 w 512bit key-size (works on Raspberry Pi 1, x86_64, 256bit)

On 02/23/2015 07:44 PM, Johannes Ernst wrote: 1. There was a (cryptic, to me) comment by one of the core Arch Linux ARM developers on my post. He said Something on my mind about kernel mode neon on imx6, can't find it now” (http://archlinuxarm.org/forum/viewtopic.php?f=60t=8489p=45395#p45364)

Re: [PATCH] avoid excessive use of socket buffer in skcipher

On 09/04/2014 09:08 AM, Herbert Xu wrote: On Mon, Aug 25, 2014 at 11:49:54AM +0200, Ondrej Kozina wrote: On archs with PAGE_SIZE = 64 KiB the function skcipher_alloc_sgl() fails with -ENOMEM no matter what user space actually requested. This is caused by the fact sock_kmalloc call inside the

Re: Kernel crypto API: cryptoperf performance measurement

On 08/20/2014 03:25 PM, Jussi Kivilinna wrote: One to four GB per second for XTS? 12 GB per second for AES CBC? Somehow that does not sound right. Agreed, those do not look correct... I wonder what happened there. On new run, I got more sane results: Which cryptsetup version are you

[PATCH] crypto: properly label AF_ALG socket

the parent sock and resolves the issue (similar to AF_BLUETOOTH protocol family). Cc: sta...@vger.kernel.org Signed-off-by: Milan Broz gmazyl...@gmail.com --- crypto/af_alg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/crypto/af_alg.c b/crypto/af_alg.c index 966f893..6a3ad80 100644

[PATCH] algif_skcipher: Avoid crash if buffer is not multiple of cipher block size

is present in all stable kernels as well.) Signed-off-by: Milan Broz gmazyl...@gmail.com --- crypto/algif_skcipher.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c index 6a6dfc0..5f7713b 100644 --- a/crypto/algif_skcipher.c

Re: [PATCH] algif_skcipher: Avoid crash if buffer is not multiple of cipher block size

On 04/14/2013 06:12 PM, Milan Broz wrote: When user requests encryption (or decryption) of block which is not aligned to cipher block size through userspace crypto interface, an OOps like this can happen And this is a reproducer for the problem above... Milan /* * Check for unaligned

Re: Tcrypt hmac(crc32) test can work only on Blackfin

On 11/21/2012 12:29 PM, Zhang, Sonic wrote: Is there a policy that the CRC test vector in testmgr.h should support all CRC drivers? If so, I am fine to drop this test vector. Question for Herbert... But the problem I see is that it confuses people, it simply returns fail everytime (except

Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target

On 09/24/2012 06:20 PM, Kasatkin, Dmitry wrote: So it can provide confidentiality but it CANNOT provide integrity protection. Yes, it provides confidentiality and via encryption it provides certain level of integrity protection. Data cannot be modified without being detected. Decryption

Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target

On 09/24/2012 11:55 AM, Dmitry Kasatkin wrote: Both dm-verity and dm-crypt provide block level integrity protection. This is not correct. dm-crypt is transparent block encryption target, where always size of plaintext == size of ciphertext. So it can provide confidentiality but it CANNOT

[PATCH] crypto: allow aesni-intel and ghash_clmulni-intel in fips mode

with alg: No test for __cbc-aes-aesni (cryptd(__driver-cbc-aes-aesni)) alg: No test for __gcm-aes-aesni (cryptd(__driver-gcm-aes-aesni)) Signed-off-by: Milan Broz mb...@redhat.com Signed-off-by: Paul Wouters pwout...@redhat.com --- crypto/testmgr.c | 38

[PATCH] crypto: aesni-intel - fix wrong kfree pointer

kfree(new_key_mem) in rfc4106_set_key() should be called on malloced pointer, not on aligned one, otherwise it can cause invalid pointer on free. (Seen at least once when running tcrypt tests with debug kernel.) Signed-off-by: Milan Broz mb...@redhat.com --- arch/x86/crypto/aesni-intel_glue.c

Re: Status of aes in Debian/Ubuntu?

On 03/28/2012 10:42 PM, Dale Amon wrote: So does anyone have a suggestion as to where I have gone wrong? It's been over half a decade since I've gone through this and even longer since I was doing the magic dance with patching and building my own losetup, mount, etc... If you want something

Re: aesni-intel as module = cryptsetup failure

On 05/07/2011 04:21 AM, Andrew Lutomirski wrote: I just moved my boot disk from an old machine to a new machine. The new machine has AES-NI and it failed to boot. The problem appears to be that aesni-intel, when loaded as a module, makes cryptsetup fail on an aes-xts-plain drive. The error

Re: aesni-intel slower than aes-x86_64

On 04/12/2010 12:52 AM, john terragon wrote: My system has a core i5 520M and supports AES-NI. I wanted to do a rude performance test and so I ran these commands on a small (4GB) partition and on the dm-crypt device backed by it: 1) using the aesni-intel module: dd if=/dev/dev/mapper/vol

Re: device-mapper: remove ioctl failed: device or resource busy

On 02/06/2010 04:32 AM, Bai Shuwei wrote: I port the xts-aes algorithm to FPGA board and use it to encrypt/decrypt the disc. i will get the bellow information But when excute the bellow commands cryptsetup luksFormat -c aes-xts-plain -s 256 /dev/loop0 or cryptsetup luksOpen

Re: how the key is generated?

On 01/27/2010 04:21 AM, Bai Shuwei wrote: On Tue, Jan 26, 2010 at 4:58 PM, Milan Broz mb...@redhat.com wrote: I use dmsetup table --showkeys get the bellow information. disk$ sudo dmsetup table --showkeys /dev/mapper/dsi0 0 2040 crypt aes-xts-plain

Re: how the key is generated?

On 01/26/2010 09:41 AM, Bai Shuwei wrote: Hello, everyone: i add one line in the setkey function which is in xts.c file to print the in_key value. I find the key value not same i set in the keyfile by cryptsetup my command is # cryptsetup luksFormat -d my_keyfile -c xts-aes-plain

Re: [PATCH] dm-crypt: disable block encryption with arc4

On 01/26/2010 10:22 AM, Sebastian Andrzej Siewior wrote: * Milan Broz | 2010-01-25 19:39:11 [+0100]: On 01/25/2010 07:29 PM, Mikulas Patocka wrote: When using arc4 to encrypt a block device, the resulting device is unreliable. It reads garbage. That's because arc4 is a stream cipher, if you

Re: [PATCH] dm-crypt: disable block encryption with arc4

On 01/25/2010 07:29 PM, Mikulas Patocka wrote: Hi When using arc4 to encrypt a block device, the resulting device is unreliable. It reads garbage. That's because arc4 is a stream cipher, if you write something, it advances its state and if you attempt to decrypt the same sector, it uses

Re: [PATCH 1/4] dm-crypt: clarify cipher vs. cipher mode

On 12/29/2009 10:21 AM, Richard Zidlicky wrote: On Mon, Dec 28, 2009 at 08:37:43PM +0100, Milan Broz wrote: While we are at it - are you aware of any documentation of the mainline dm-crypt implementation? I have not seen anything, much less any explanation if it has improved any since

Re: [PATCH 1/4] dm-crypt: clarify cipher vs. cipher mode

On 12/28/2009 07:59 PM, Max Vozeler wrote: The original code used cc-cipher for two things: @@ -1014,6 +1014,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv) char *ivopts; unsigned int key_size; unsigned long long tmpll; + char

Re: [dm-crypt] cryptsetup with arc4 cipher

Sebastian Andrzej Siewior wrote: Don't use this as a block cipher in dm-crypt, it is a bad idea. The long story: ARC4 is a stream cipher and not a block cipher. Its internal state is reseted in setkey() and every crypto request (encrypt/decrypt don't matter) update the internal state of

Re: [dm-devel] Re: NULL data pointer dereference in kcryptd

Herbert Xu wrote: On Fri, Jul 31, 2009 at 10:54:45PM +0200, Michael Buesch wrote: [15577.988608] NIP [c00b8034] .mempool_alloc+0x74/0x1a0 [15577.988614] LR [c0139bdc] .bio_alloc_bioset+0x4c/0x130 [15577.988616] Call Trace: [15577.988619] [c001f022fb60] [c001f022fbf0]

Re: [2.6.28.5] dm/crypt oops: unable to handle kernel NULL pointer dereference (tainted)

Melchior FRANZ wrote: umount ... cryptsetup remove ... losetup -d ... BUG: unable to handle kernel NULL pointer dereference at 0004 IP: [c0158a75] mempool_free+0xd/0x9a ... Yes, I know about that problem and I am almost sure that it is fixed by patch I sent there

Re: dm/crypt oops in 2.6.28.5 ... but nvidia users aren't supposed to report?

Melchior FRANZ wrote: I was about to report an oops in the crypt module (NULL pointer dereferencing), but when I was half-way through entering the bug in bugzilla, I read that people with nvidia tainted kernels aren't supposed to file bug reports. So the bug is going to remain unfixed!?

Re: Bug of dm-crypt?

Herbert Xu wrote: On Fri, Feb 27, 2009 at 01:31:56PM +0800, Huang Ying wrote: I had ever heard from you that the only thing guaranteed in the completion function of async ablkcipher cryption is the req-data has the value you set before. The request pointer itself may be changed. But in

Re: [BUGFIX] dm-crypt: Fix a bug of async cryption complete function

Herbert Xu wrote: On Fri, Feb 27, 2009 at 04:56:11PM +0800, Huang Ying wrote: @@ -830,7 +838,7 @@ static void kcryptd_async_done(struct cr return; } -mempool_free(ablkcipher_request_cast(async_req), cc-req_pool); +mempool_free(dmreq-req, cc-req_pool); Why do

Re: [BUGFIX] dm-crypt: Fix a bug of async cryption complete function

Herbert Xu wrote: On Fri, Feb 27, 2009 at 12:52:05PM +0100, Milan Broz wrote: Herbert Xu wrote: On Fri, Feb 27, 2009 at 04:56:11PM +0800, Huang Ying wrote: @@ -830,7 +838,7 @@ static void kcryptd_async_done(struct cr return; } - mempool_free(ablkcipher_request_cast

Re: [BUGFIX] dm-crypt: Fix a bug of async cryption complete function

Herbert Xu wrote: On Fri, Feb 27, 2009 at 01:28:46PM +0100, Milan Broz wrote: Like this? struct ablkcipher_request *req = (char *)dmreq - cc-dmreq_start; mempool_free(req, cc-req_pool); Exactly. You could also embed the ablkcipher_request at the end of dmreq, as in struct

Re: [dm-devel] Re: next-20081125: crypto hard disk gets unaccessable

Andrew Morton wrote: (cc's added) After about four suspend resume operations in the midst of editing a file, the system beeped twice and issued this error: Did this work before? If so, please can you provide version where it works? It is suspend to encrypted swap? There should not be any

Re: [dm-devel] [PATCH 1/3] [DM] dm-crypt: Move post-processing into its own queue

Hi Herbert, Herbert Xu wrote: [DM] dm-crypt: Move post-processing into its own queue + _kcryptd_io_workqueue = create_workqueue(kcryptd-io); Adding another qlobal per-cpu queue can lead to wasteful creating of too many kernel threads in system (system with many cores etc.) I have