[PATCH v6 0/2] IV Generation algorithms for dm-crypt

process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (2): crypto: Add IV generation algorithms crypto: Multikey template for essiv drivers/md/dm-crypt.c| 1940 +++--- drivers/staging

[PATCH v6 0/2] IV Generation algorithms for dm-crypt

process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (2): crypto: Add IV generation algorithms crypto: Multikey template for essiv drivers/md/dm-crypt.c| 1940 +++--- drivers/staging

[PATCH v6 1/2] crypto: Add IV generation algorithms

/decrypt a sector are processed sequentially. Asynchronous requests if processed in parallel, are freed in the async callback. The storage space for the initialization vectors are allocated in the iv generator implementations. Interface to the crypto layer - include/crypto/geniv.h Signed-off-by: Binoy

[PATCH v6 1/2] crypto: Add IV generation algorithms

/decrypt a sector are processed sequentially. Asynchronous requests if processed in parallel, are freed in the async callback. The storage space for the initialization vectors are allocated in the iv generator implementations. Interface to the crypto layer - include/crypto/geniv.h Signed-off-by: Binoy

[PATCH v6 2/2] crypto: Multikey template for essiv

it was written for. The underlying IV generator 'essiv-aes-du512-dx' generates IV for every 512 byte blocks. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/md/dm-crypt.c|5 +- drivers/staging/ccree/Makefile |2 +- drivers/staging/ccree/essiv.c

[PATCH v6 2/2] crypto: Multikey template for essiv

it was written for. The underlying IV generator 'essiv-aes-du512-dx' generates IV for every 512 byte blocks. Signed-off-by: Binoy Jayan --- drivers/md/dm-crypt.c|5 +- drivers/staging/ccree/Makefile |2 +- drivers/staging/ccree/essiv.c| 777

[PATCH v4] HID: Remove the semaphore driver_lock

The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as suggested by Arnd. Hence removing it, as the concurrency between the probe and remove is already handled in the driver core. Suggested-by: Arnd Bergmann <a...@arndb.de> Signed-off-by: Binoy Jayan <

[PATCH v4] HID: Remove the semaphore driver_lock

The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as suggested by Arnd. Hence removing it, as the concurrency between the probe and remove is already handled in the driver core. Suggested-by: Arnd Bergmann Signed-off-by: Binoy Jayan Acked-by: Benjamin Tissoires

[PATCH v3] HID: Replace semaphore driver_lock with mutex

The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as suggested by Arnd. Hence removing it, as the concurrency between the probe and remove is already handled in the driver core. Suggested-by: Arnd Bergmann <a...@arndb.de> Signed-off-by: Binoy Jayan <

[PATCH v3] HID: Replace semaphore driver_lock with mutex

The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as suggested by Arnd. Hence removing it, as the concurrency between the probe and remove is already handled in the driver core. Suggested-by: Arnd Bergmann Signed-off-by: Binoy Jayan Acked-by: Benjamin Tissoires

Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

Hi, On 14 June 2017 at 01:55, Arnd Bergmann wrote: >> The mutex code clearly states mutex_trylock() must not be used in >> interrupt context (see kernel/locking/mutex.c), hence we used a >> semaphore here. Unless the mutex code is changed to allow this, we >> cannot switch away

Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

Hi, On 14 June 2017 at 01:55, Arnd Bergmann wrote: >> The mutex code clearly states mutex_trylock() must not be used in >> interrupt context (see kernel/locking/mutex.c), hence we used a >> semaphore here. Unless the mutex code is changed to allow this, we >> cannot switch away from semaphores.

Re: [PATCH v2 0/3] ngene: Replace semaphores with mutexes

Hi Arnd, On 13 June 2017 at 15:19, Arnd Bergmann <a...@arndb.de> wrote: > On Tue, Jun 13, 2017 at 10:58 AM, Binoy Jayan <binoy.ja...@linaro.org> wrote: >> These are a set of patches [v2] which removes semaphores from ngene. >> These are part of a bigger effort to el

Re: [PATCH v2 0/3] ngene: Replace semaphores with mutexes

Hi Arnd, On 13 June 2017 at 15:19, Arnd Bergmann wrote: > On Tue, Jun 13, 2017 at 10:58 AM, Binoy Jayan wrote: >> These are a set of patches [v2] which removes semaphores from ngene. >> These are part of a bigger effort to eliminate unwanted semaphores >> from the linux

Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

Hi Arnd, On 13 June 2017 at 15:15, Arnd Bergmann wrote: > Looks good to me, but I see you didn't include David and Andrew on > Cc, it would be good for at least one of them to provide an Ack as well. Will include them, thank you yet again for reminding me. > You forgot to

Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

Hi Arnd, On 13 June 2017 at 15:15, Arnd Bergmann wrote: > Looks good to me, but I see you didn't include David and Andrew on > Cc, it would be good for at least one of them to provide an Ack as well. Will include them, thank you yet again for reminding me. > You forgot to actually drop the

Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

Hi, On 13 June 2017 at 15:26, Benjamin Tissoires wrote: >> Looks good to me, but I see you didn't include David and Andrew on >> Cc, it would be good for at least one of them to provide an Ack as well. > > Please also CC linux-input@ Will do that. > (one more

Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

Hi, On 13 June 2017 at 15:26, Benjamin Tissoires wrote: >> Looks good to me, but I see you didn't include David and Andrew on >> Cc, it would be good for at least one of them to provide an Ack as well. > > Please also CC linux-input@ Will do that. > (one more nitpick below too) > A little bit

[PATCH v2] HID: Replace semaphore driver_lock with mutex

The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as suggested by Arnd. Hence removing it, as the concurrency between the probe and remove is already handled in the driver core. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> Suggested-by: Arnd Be

[PATCH v2] HID: Replace semaphore driver_lock with mutex

The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as suggested by Arnd. Hence removing it, as the concurrency between the probe and remove is already handled in the driver core. Signed-off-by: Binoy Jayan Suggested-by: Arnd Bergmann --- v1 --> v2 Removed driver_l

[PATCH v2 3/3] media: ngene: Replace semaphore i2c_switch_mutex with mutex

The semaphore 'i2c_switch_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/media/pci/ngene/ngene-core.c | 2 +- drivers/media/pci/ngene/ngene-i2c.c | 6 +++--- drivers

[PATCH v2 3/3] media: ngene: Replace semaphore i2c_switch_mutex with mutex

The semaphore 'i2c_switch_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- drivers/media/pci/ngene/ngene-core.c | 2 +- drivers/media/pci/ngene/ngene-i2c.c | 6 +++--- drivers/media/pci/ngene/ngene.h

Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

Hi Arnd, On 9 June 2017 at 16:06, Arnd Bergmann wrote: >> Thank you for pointing out that. I'll check the >> concurrency part. By the way why do we need mutex_destoy? >> To debug an aberrate condition? > > At first I suspected the down() here was added for the same > purpose as a

Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

Hi Arnd, On 9 June 2017 at 16:06, Arnd Bergmann wrote: >> Thank you for pointing out that. I'll check the >> concurrency part. By the way why do we need mutex_destoy? >> To debug an aberrate condition? > > At first I suspected the down() here was added for the same > purpose as a mutex_destroy:

[PATCH v2 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

The semaphore 'cmd_mutex' is used as a simple mutex, so it should be written as one. Also, replace down with mutex_destroy to ensure sane state when ngene_stop is called. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/media/pci/ngene/ngene-core.c | 12 ++-- drivers

[PATCH v2 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

The semaphore 'cmd_mutex' is used as a simple mutex, so it should be written as one. Also, replace down with mutex_destroy to ensure sane state when ngene_stop is called. Signed-off-by: Binoy Jayan --- drivers/media/pci/ngene/ngene-core.c | 12 ++-- drivers/media/pci/ngene/ngene.h

[PATCH v2 0/3] ngene: Replace semaphores with mutexes

c.c | 6 +++--- drivers/media/pci/ngene/ngene.h | 6 +++--- 3 files changed, 20 insertions(+), 24 deletions(-) -- Binoy Jayan

[PATCH v2 2/3] media: ngene: Replace semaphore stream_mutex with mutex

The semaphore 'stream_mutex' is used as a simple mutex, so it should be written as one. Also moving the mutex_[lock/unlock] to the caller as it is anyway locked at the beginning of the callee thus avoiding repetition. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/med

[PATCH v2 0/3] ngene: Replace semaphores with mutexes

c.c | 6 +++--- drivers/media/pci/ngene/ngene.h | 6 +++--- 3 files changed, 20 insertions(+), 24 deletions(-) -- Binoy Jayan

[PATCH v2 2/3] media: ngene: Replace semaphore stream_mutex with mutex

The semaphore 'stream_mutex' is used as a simple mutex, so it should be written as one. Also moving the mutex_[lock/unlock] to the caller as it is anyway locked at the beginning of the callee thus avoiding repetition. Signed-off-by: Binoy Jayan --- drivers/media/pci/ngene/ngene-core.c | 18

Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

On 8 June 2017 at 20:40, Arnd Bergmann <a...@arndb.de> wrote: > On Thu, Jun 8, 2017 at 12:04 PM, Binoy Jayan <binoy.ja...@linaro.org> wrote: >> The semaphore 'cmd_mutex' is used as a simple mutex, so >> it should be written as one. Semaphores are going away in t

Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

On 8 June 2017 at 20:40, Arnd Bergmann wrote: > On Thu, Jun 8, 2017 at 12:04 PM, Binoy Jayan wrote: >> The semaphore 'cmd_mutex' is used as a simple mutex, so >> it should be written as one. Semaphores are going away in the future. >> >> Signed-off-by: Binoy Jayan >

[PATCH 0/2] esas2r: Replace semaphores with mutexes

These are a set of patches which removes semaphores from esas2r. These are part of a bigger effort to eliminate unwanted semaphores from the linux kernel. Binoy Jayan (2): scsi: esas2r: Replace semaphore fm_api_semaphore with mutex scsi: esas2r: Replace semaphore fs_api_semaphore with mutex

[PATCH 0/2] esas2r: Replace semaphores with mutexes

These are a set of patches which removes semaphores from esas2r. These are part of a bigger effort to eliminate unwanted semaphores from the linux kernel. Binoy Jayan (2): scsi: esas2r: Replace semaphore fm_api_semaphore with mutex scsi: esas2r: Replace semaphore fs_api_semaphore with mutex

[PATCH 1/2] scsi: esas2r: Replace semaphore fm_api_semaphore with mutex

The semaphore 'fm_api_semaphore' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/scsi/esas2r/esas2r.h | 2 +- drivers/scsi/esas2r/esas2r_init.c | 2 +- drivers/scsi/

[PATCH 1/2] scsi: esas2r: Replace semaphore fm_api_semaphore with mutex

The semaphore 'fm_api_semaphore' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- drivers/scsi/esas2r/esas2r.h | 2 +- drivers/scsi/esas2r/esas2r_init.c | 2 +- drivers/scsi/esas2r/esas2r_ioctl.c | 4

[PATCH 2/2] scsi: esas2r: Replace semaphore fs_api_semaphore with mutex

The semaphore 'fs_api_semaphore' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/scsi/esas2r/esas2r.h | 2 +- drivers/scsi/esas2r/esas2r_init.c | 2 +- drivers/scsi/

[PATCH 2/2] scsi: esas2r: Replace semaphore fs_api_semaphore with mutex

The semaphore 'fs_api_semaphore' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- drivers/scsi/esas2r/esas2r.h | 2 +- drivers/scsi/esas2r/esas2r_init.c | 2 +- drivers/scsi/esas2r/esas2r_ioctl.c | 6

[PATCH 3/3] media: ngene: Replace semaphore i2c_switch_mutex with mutex

The semaphore 'i2c_switch_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/media/pci/ngene/ngene-core.c | 2 +- drivers/media/pci/ngene/ngene-i2c.c | 6 +++--- drivers

[PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

The semaphore 'cmd_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/media/pci/ngene/ngene-core.c | 12 ++-- drivers/media/pci/ngene/ngene.h | 2 +- 2

[PATCH 3/3] media: ngene: Replace semaphore i2c_switch_mutex with mutex

The semaphore 'i2c_switch_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- drivers/media/pci/ngene/ngene-core.c | 2 +- drivers/media/pci/ngene/ngene-i2c.c | 6 +++--- drivers/media/pci/ngene/ngene.h

[PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

The semaphore 'cmd_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- drivers/media/pci/ngene/ngene-core.c | 12 ++-- drivers/media/pci/ngene/ngene.h | 2 +- 2 files changed, 7 insertions(+), 7

[PATCH 2/3] media: ngene: Replace semaphore stream_mutex with mutex

The semaphore 'stream_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/media/pci/ngene/ngene-core.c | 14 +++--- drivers/media/pci/ngene/ngene.h | 2 +- 2

[PATCH 0/3] ngene: Replace semaphores with mutexes

These are a set of patches which removes semaphores from ngene. These are part of a bigger effort to eliminate unwanted semaphores from the linux kernel. Binoy Jayan (3): media: ngene: Replace semaphore cmd_mutex with mutex media: ngene: Replace semaphore stream_mutex with mutex media

[PATCH 2/3] media: ngene: Replace semaphore stream_mutex with mutex

The semaphore 'stream_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- drivers/media/pci/ngene/ngene-core.c | 14 +++--- drivers/media/pci/ngene/ngene.h | 2 +- 2 files changed, 8 insertions

[PATCH 0/3] ngene: Replace semaphores with mutexes

These are a set of patches which removes semaphores from ngene. These are part of a bigger effort to eliminate unwanted semaphores from the linux kernel. Binoy Jayan (3): media: ngene: Replace semaphore cmd_mutex with mutex media: ngene: Replace semaphore stream_mutex with mutex media

[PATCH] net: ethernet: micrel: ksz884x: Replace semaphore proc_sem with mutex

The semaphore 'proc_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel. drive

[PATCH] net: ethernet: micrel: ksz884x: Replace semaphore proc_sem with mutex

The semaphore 'proc_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel. drivers/net/ethernet/micrel/ksz884x.c | 10

[PATCH] mwifiex: Replace semaphore async_sem with mutex

The semaphore 'async_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel. drive

[PATCH] mwifiex: Replace semaphore async_sem with mutex

The semaphore 'async_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel. drivers/net/wireless/marvell/mwifiex

[PATCH] HID: Replace semaphore driver_lock with mutex

The semaphore 'driver_lock' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel. drivers/h

[PATCH] HID: Replace semaphore driver_lock with mutex

The semaphore 'driver_lock' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel. drivers/hid/hid-core.c | 10

[ACTIVITY] (Binoy Jayan) 2017-05-08 to 2017-05-15

=== Binoy Jayan === === Highlights === dm-crypt optimization - No progress dm-crypt:store keys in secure storage - Read OPTEE ClientAPI specification to figure out how to communicate with optee from a client application - No examples available for using client api from kernel so need

[ACTIVITY] (Binoy Jayan) 2017-05-08 to 2017-05-15

=== Binoy Jayan === === Highlights === dm-crypt optimization - No progress dm-crypt:store keys in secure storage - Read OPTEE ClientAPI specification to figure out how to communicate with optee from a client application - No examples available for using client api from kernel so need

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

Hi Milan, On 10 April 2017 at 19:30, Milan Broz wrote: Thank you for the reply. > Well, it is good that there is no performance degradation but it > would be nice to have some user of it that proves it is really > working for your hw. I have been able to get access to a

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

Hi Milan, On 10 April 2017 at 19:30, Milan Broz wrote: Thank you for the reply. > Well, it is good that there is no performance degradation but it > would be nice to have some user of it that proves it is really > working for your hw. I have been able to get access to a hardware with IV

[RFC PATCH v5] crypto: Add IV generation algorithms

/geniv.h Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/md/dm-crypt.c | 1916 ++-- include/crypto/geniv.h | 47 ++ 2 files changed, 1424 insertions(+), 539 deletions(-) create mode 100644 include/crypto/geniv.h diff --git a/drivers

[RFC PATCH v5] crypto: Add IV generation algorithms

/geniv.h Signed-off-by: Binoy Jayan --- drivers/md/dm-crypt.c | 1916 ++-- include/crypto/geniv.h | 47 ++ 2 files changed, 1424 insertions(+), 539 deletions(-) create mode 100644 include/crypto/geniv.h diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm

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

sts using mempool v1 --> v2 -- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (1): crypto: Add IV generation algorithms drivers/md/dm-crypt.c | 1916 ++---

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

sts using mempool v1 --> v2 -- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (1): crypto: Add IV generation algorithms drivers/md/dm-crypt.c | 1916 ++---

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

On 6 March 2017 at 20:08, Gilad Ben-Yossef wrote: > > I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and > on Arm using CryptoCell hardware accelerator. > > There was no difference in performance between 512 and 4096 bytes > cluster size on the x86_64 (800

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

On 6 March 2017 at 20:08, Gilad Ben-Yossef wrote: > > I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and > on Arm using CryptoCell hardware accelerator. > > There was no difference in performance between 512 and 4096 bytes > cluster size on the x86_64 (800 MB loop file system)

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

Hi Herbert, On 8 February 2017 at 13:02, Gilad Ben-Yossef <gi...@benyossef.com> wrote: > On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan <binoy.ja...@linaro.org> wrote: >> === >> dm-crypt optimiza

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

Hi Herbert, On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote: > On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan wrote: >> === >> dm-crypt optimization for lar

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

On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote: > > Ran Bonnie++ on it last night (Luks mode, plain64, Qemu Virt platform > Arm64) and it works just fine. > > Tested-by: Gilad Ben-Yossef > Hi Gilad, Thank you for testing it. Do you have access to

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

On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote: > > Ran Bonnie++ on it last night (Luks mode, plain64, Qemu Virt platform > Arm64) and it works just fine. > > Tested-by: Gilad Ben-Yossef > Hi Gilad, Thank you for testing it. Do you have access to a device having crypto hardware with IV

[RFC PATCH v4] crypto: Add IV generation algorithms

/geniv.h Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/md/dm-crypt.c | 1894 ++-- include/crypto/geniv.h | 47 ++ 2 files changed, 1402 insertions(+), 539 deletions(-) create mode 100644 include/crypto/geniv.h diff --git a/drivers

[RFC PATCH v4] crypto: Add IV generation algorithms

/geniv.h Signed-off-by: Binoy Jayan --- drivers/md/dm-crypt.c | 1894 ++-- include/crypto/geniv.h | 47 ++ 2 files changed, 1402 insertions(+), 539 deletions(-) create mode 100644 include/crypto/geniv.h diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm

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

cessed in parallel and is freed in the async callback. 4. Changed allocation for sub-requests using mempool v1 --> v2 -- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (1): crypto: Add IV g

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

cessed in parallel and is freed in the async callback. 4. Changed allocation for sub-requests using mempool v1 --> v2 -- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (1): crypto: Add IV g

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

Hi Gilad, On 19 January 2017 at 15:17, Gilad Ben-Yossef wrote: > I tried adding sg_init_table() where I thought it was appropriate and > it didn't resolve the issue. > > For what it's worth, my guess is that the difference between our > setups is not related to Arm but to

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

Hi Gilad, On 19 January 2017 at 15:17, Gilad Ben-Yossef wrote: > I tried adding sg_init_table() where I thought it was appropriate and > it didn't resolve the issue. > > For what it's worth, my guess is that the difference between our > setups is not related to Arm but to other options or the

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

Hi Gilad, On 18 January 2017 at 20:51, Gilad Ben-Yossef wrote: > I have some review comments and a bug report - Thank you very much for testing this on ARM and for the comments. > I'm pretty sure this needs to be > > n2 = bio_segments(ctx->bio_out); Yes you are right,

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

Hi Gilad, On 18 January 2017 at 20:51, Gilad Ben-Yossef wrote: > I have some review comments and a bug report - Thank you very much for testing this on ARM and for the comments. > I'm pretty sure this needs to be > > n2 = bio_segments(ctx->bio_out); Yes you are right, that was a typo :) >>

[RFC PATCH v3] crypto: Add IV generation algorithms

/geniv.h Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org> --- drivers/md/dm-crypt.c | 1891 ++-- include/crypto/geniv.h | 47 ++ 2 files changed, 1399 insertions(+), 539 deletions(-) create mode 100644 include/crypto/geniv.h diff --git a/drivers

[RFC PATCH v3] crypto: Add IV generation algorithms

/geniv.h Signed-off-by: Binoy Jayan --- drivers/md/dm-crypt.c | 1891 ++-- include/crypto/geniv.h | 47 ++ 2 files changed, 1399 insertions(+), 539 deletions(-) create mode 100644 include/crypto/geniv.h diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm

[RFC PATCH v3] IV Generation algorithms for dm-crypt

eed in the async callback. 4. Changed allocation for sub-requests using mempool v1 --> v2 -- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (1): crypto: Add IV generation algorithms drivers

[RFC PATCH v3] IV Generation algorithms for dm-crypt

eed in the async callback. 4. Changed allocation for sub-requests using mempool v1 --> v2 -- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (1): crypto: Add IV generation algorithms drivers

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

Hi Herbert, On 2 January 2017 at 12:23, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote: > > Right. The actual number of underlying tfms that do the work > won't change compared to the status quo. We'r

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

Hi Herbert, On 2 January 2017 at 12:23, Herbert Xu wrote: > On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote: > > Right. The actual number of underlying tfms that do the work > won't change compared to the status quo. We're just structuring > it such that if the

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

Hi Gilad, On 3 January 2017 at 19:53, Gilad Ben-Yossef wrote: > Good idea. I wanted to test the patch but alas it does not apply cleanly. > You seem to have a blank line at the end of files and other small > transgressions that makes checkpatch grumpy. I think that is

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

Hi Gilad, On 3 January 2017 at 19:53, Gilad Ben-Yossef wrote: > Good idea. I wanted to test the patch but alas it does not apply cleanly. > You seem to have a blank line at the end of files and other small > transgressions that makes checkpatch grumpy. I think that is because there were some

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

On 2 January 2017 at 12:23, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote: >> >> Even if ciphers are allocated this way, all the encryption requests >> for cbc should still go through IV generators? So that

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

On 2 January 2017 at 12:23, Herbert Xu wrote: > On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote: >> >> Even if ciphers are allocated this way, all the encryption requests >> for cbc should still go through IV generators? So that should mean, >> create o

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

Hi Herbert, On 30 December 2016 at 15:57, Herbert Xu wrote: > This is just a matter of structuring the key for the IV generator. > The IV generator's key in this case should be a combination of the > key to the underlying CBC plus the set of all keys for the IV >

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

Hi Herbert, On 30 December 2016 at 15:57, Herbert Xu wrote: > This is just a matter of structuring the key for the IV generator. > The IV generator's key in this case should be a combination of the > key to the underlying CBC plus the set of all keys for the IV > generator itself. It should

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

: add ability to use keys from the kernel key retention service On Thu, Dec 22, 2016 at 04:25:12PM +0530, Binoy Jayan wrote: > > > It doesn't have to live outside of dm-crypt. You can register > > these IV generators from there if you really want. > > Sorry, but I didn't understa

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

: add ability to use keys from the kernel key retention service On Thu, Dec 22, 2016 at 04:25:12PM +0530, Binoy Jayan wrote: > > > It doesn't have to live outside of dm-crypt. You can register > > these IV generators from there if you really want. > > Sorry, but I didn't understa

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

Hi Herbert, On 22 December 2016 at 14:25, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote: >> >> By the move everything to cryptoAPI we are basically introducing some >> strange mix >> of IV and modes there, I wonder how this is going

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

Hi Herbert, On 22 December 2016 at 14:25, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote: >> >> By the move everything to cryptoAPI we are basically introducing some >> strange mix >> of IV and modes there, I wonder how this is going to be maintained. >> Anyway,

Re: dm-crypt optimization

Hi Milan, On 21 December 2016 at 18:17, Milan Broz wrote: > So the core problem is that your crypto accelerator can operate efficiently > only > with bigger batch sizes. Thank you for the reply. Yes, that would be rather an improvement when having bigger block sizes. >

Re: dm-crypt optimization

Hi Milan, On 21 December 2016 at 18:17, Milan Broz wrote: > So the core problem is that your crypto accelerator can operate efficiently > only > with bigger batch sizes. Thank you for the reply. Yes, that would be rather an improvement when having bigger block sizes. > How big blocks your

dm-crypt optimization

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 manually implements ESSIV and similar algorithms which

dm-crypt optimization

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 manually implements ESSIV and similar algorithms which

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

Hi Milan, On 13 December 2016 at 15:31, Milan Broz wrote: > I think that IV generators should not modify or read encrypted data directly, > it should only generate IV. I was trying to find more information about what you said and how a iv generator should be written. I saw

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

Hi Milan, On 13 December 2016 at 15:31, Milan Broz wrote: > I think that IV generators should not modify or read encrypted data directly, > it should only generate IV. I was trying to find more information about what you said and how a iv generator should be written. I saw two examples of IV

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

Hi Milan, Thank you for the reply. On 13 December 2016 at 15:31, Milan Broz wrote: > I really do not think the disk encryption key management should be moved > outside of dm-crypt. We cannot then change key structure later easily. Yes, I agree. but the key selection based

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

Hi Milan, Thank you for the reply. On 13 December 2016 at 15:31, Milan Broz wrote: > I really do not think the disk encryption key management should be moved > outside of dm-crypt. We cannot then change key structure later easily. Yes, I agree. but the key selection based on sector number

[RFC PATCH v2] crypto: Add IV generation algorithms

ayer, each cipher instance set with a unique subkey (part of the bigger master key) and these instances themselves do not have access to each other's instances or contexts. This way, a single instance cannot encryt/decrypt a whole bio. This has to be fixed. Not-signed-off-by: Binoy Jayan <b

[RFC PATCH v2] IV Generation algorithms for dm-crypt

-t ext4 /dev/mapper/crypt_fun /mnt <-- Use the encrypted file system --> umount /mnt cryptsetup luksClose crypt_fun cryptsetup luksRemoveKey /dev/sdb This seems to work well. The file system mounts successfully and the files written to in the file system remain persistent across reboots.

  1   2   3   4   5   >